Quartz 4

Куда маппить foundContext[] в ClinicalImpression

contested
Not verified

4 min read

Builder в worktrees/v2-5-fhir/packages/analysis-core/src/lib/fhir-clinical-impression-builder.ts сейчас пишет в .finding[] с kind="found-context" sub-extension — это противоречит FHIR R4 spec (finding[] = диагностические выводы, не background evidence). Перед FHIR-cutover (BG-1323) надо выбрать правильный slot. Между двумя кандидатами есть открытый спор.

Контекст

V2EvidenceItemOutput items в foundContext могут иметь type: "observation" | "condition" | "medication" (определение в packages/analysis-core/src/types/parameter-analysis.types.ts:192). Items собираются deterministically по graph traversal’у уже существующего patient FHIR record. Это preexisting patient data, найденная и зацитированная как evidence для assessment’а биомаркера, не newly-collected данные.

FHIR R4 ClinicalImpression имеет несколько слотов под этот семантический слой:

СлотReference typeСемантика по spec
investigation[].item[]Observation | QuestionnaireResponse | FamilyMemberHistory | DiagnosticReport | RiskAssessment | ImagingStudy | Media (closed list)“Actual data of the assessment that was collected” — input evidence
problem[]Condition | AllergyIntolerance”Relevant problems/conditions for a patient” — patient background
supportingInfo[]Reference(Any)“Information supporting the clinical impression” — type-permissive
finding[]itemCodeableConcept | Reference(Condition | Observation)Diagnostic conclusions / ruled-out states — output assessment

finding[] отброшено — это output (diagnoses), не input (evidence). Спор между двумя подходами для evidence-input.

Позиции

A. Split по type (semantic per slot)

Каждый V2EvidenceItemOutput идёт в slot, type-matched под его type:

  • type: "observation" → investigation[].item[] (Reference to Observation)
  • type: "condition" → problem[] (Reference to Condition — это ровно то, для чего slot создан)
  • type: "medication" → supportingInfo[] (нет другого слота — Medication-family Reference нигде в CI native не принимается)

Structural metadata (rationale, quotes, personalizedRationale, unmatched) живёт в bloodgpt-evidence-item extension независимо от слота.

За:

  • Каждый item в semantically-correct позиции по spec
  • FHIR consumer querying ?_include=ClinicalImpression:problem получит реальные Condition references — composability
  • Если в будущем integration partner (InterSystems, EHR vendor) делает sanity-check по profile — ничего не падает

Против:

  • Builder code разносит один логический массив по 3 слотам — больше кода, больше чтения при reconstruct в parser
  • Семантика problem[] в spec — “patient’s existing problems to track” — у нас Condition попадает туда потому что это relevant background к assessment’у, а не потому что мы tracking как problem. Близко, но не identical.
  • investigation.item definition: “data that was collected during assessment”. Наши items — preexisting, scanned by reference. Близко по смыслу, но строго по букве — collected ≠ scanned.

B. Всё в supportingInfo[] (flat, type-permissive)

Все items, независимо от type, идут одним массивом в supportingInfo[]. Type восстанавливается из Reference.reference URL pattern или из bloodgpt-evidence-item.itemType sub-extension.

За:

  • Простой builder и parser — один слот, один loop
  • Семантически точнее: “supporting information” = preexisting data scanned by reference. Это и есть наш кейс.
  • Reference(Any) — не упрётся в type-restriction независимо от того, какие новые типы появятся в V2EvidenceItemOutput.type

Против:

  • Теряется native granularity: FHIR consumer не отличит Conditions / Medications / Observations через query-time include по slot — придётся фильтровать на клиенте по resource type
  • Все 3 типа лежат вперемешку, hardcode на supportingInfo[] для всего AI evidence — будущие decision-страницы про другие AI-output ресурсы тоже должны быть aware

Что нужно для разрешения

  • Practical query patterns. Если кто-то реально будет делать _include=...:problem — (A) выигрывает. Если все downstream consumers всё равно загружают полный CI и парсят — (B) проще.
  • InterSystems / EHR partner integration response — какой mapping они ожидают на foundContext-семантику.
  • Решение по missingContext[] — оно концептуально parallel (fhir-clinical-impression open вопрос). Если missingContext тоже идёт в note[]/extension, то foundContext-в-supportingInfo даёт consistency. Если missingContext split-ится по типам — то и foundContext тоже split-ить логично.

Связано

  • fhir-clinical-impression — entity-страница, в mapping table сейчас стоит foundContext → investigation.item ✓ (требует уточнения)
  • fhir-modeling-ai-content — общие принципы маппинга AI-output в FHIR R4
  • zero-extensions-fhir — общая директива минимизации extensions; supportingInfo даёт меньше extensions, investigation/problem split — больше cross-references
  • edge-role-encoding — параллельный sub-вопрос: если split-per-type (A), role на edge может быть выведен из slot и наоборот; если unified supportingInfo (B), role нужен как explicit extension

Источники

Источники: 1.

Сноски

  1. FHIR R4 ClinicalImpression, accessed 2026-05-17, https://hl7.org/fhir/R4/clinicalimpression.html. ↩

Graph View

Backlinks