Эта страница фиксирует, какие имена выбраны для системы Health Report и какие альтернативы отвергнуты. Конкретный pipeline-flow — health-report-pipeline; paradigm motivation — health-report-vision; per-biomarker внутренности — biomarker-analysis-pipeline.

Зачем фиксировать имена

Команда пишет код, спецификации, тикеты, документацию — и если каждый называет одно и то же по-разному, понимание разъезжается. Главная задача страницы — закрепить выбранные имена и аргументы за ними, чтобы новые решения могли опираться на этот словарь, а не изобретать слова заново.

Слой 1 — артефакт: Health Report

То, что выдаёт пайплайн. Один на пациента (плюс версии в FHIR _history).

Рассматривали:

  • Report (без префикса) — короче. Минус: коллизия с FHIR DiagnosticReport (per-test lab document) — в разговорах «report» начинает значить две разные вещи.
  • Snapshot — изначально использовалось в health-snapshot-vision. Минус: «snapshot» хорошо ложится на «срез данных на момент», но не на их интерпретацию. Артефакт — не данные, а синтез поверх них; имя должно сигналить уровень синтеза.
  • Patient Summary — соответствует HL7 IPS-стандарту, на который мы вдохновлялись. Минус: слово summary мы уже используем в двух других смыслах — для IPS-документа и для retrieval-этапа (см. patient-summary — это страница про то, как мы собираем входные FHIR-данные для LLM, не про output). Тройное значение разводит понимание.
  • Health Report — выбрано.

Почему Health Report:

  • Префикс Health снимает коллизию с DiagnosticReport (test-scoped): наш Health Report patient-scoped и про общее здоровье.
  • «Report» команде понятен, не клинически-зашорен. Раньше у нас были «test reports» — теперь появляется «health report» как параллель.
  • Естественно говорится: «AI составил отчёт по тебе на дату X».
  • Парадигмальный сдвиг (тест-центрик → пациент-центрик) звучит как «от Lab Report к Health Report» — слово «report» сохраняется, меняется префикс.

Слой 2 — вход в пайплайн: Snapshot

То, что пайплайн получает на вход. Срез данных пациента: observations (по одному latest на биомаркер после actuality-фильтра), активные диагнозы, активные лекарства, демография.

Рассматривали:

  • Patient Context — текущее имя в коде (V2PatientContext). Минус: слишком generic — «контекст» бывает разный, и не виден point-in-time характер (наш Snapshot привязан к as-of-дате, это важная часть смысла).
  • Patient State — clinical, но «state» не передаёт временной слой так же хорошо, как «snapshot».
  • Slice / Срез — естественно по-русски, но в английском не term-of-art.
  • Snapshot — выбрано.

Почему Snapshot:

  • Точно передаёт идею «срез на момент» (важно для as-of-date семантики).
  • Освободилось после переименования артефакта: раньше Snapshot иногда значил артефакт, теперь — строго про curated input data.
  • Слой и его роль становятся видимыми в hierarchy: «Pipeline берёт Snapshot и делает Health Report».

Слой 3 — секции внутри Health Report: Insights

Тематические narrative-разделы, которые видит пользователь. Сейчас в работе пять секций (структура из daily 2026-04-27, Вася).

Рассматривали:

  • Sections — нейтрально, но безлико (имя из FHIR Composition.section[] — это storage shape, не human-facing concept).
  • Findings — clinical-natural, FHIR-aligned (ClinicalImpression.finding[]). Минус: по-русски «находки» звучит странно и слишком безлико. FHIR finding[] ещё и работает как per-CI atomic conclusions — наши секции крупнее, целые narrative-блоки.
  • Highlights — Apple-style, friendly. Минус: «highlights» подразумевает выборку «лучшего» — а у нас в зонт входят и «что меняется», и «чего не хватает», не только важное. Подходит как имя ОДНОЙ из секций (см. ниже), не зонта.
  • Insights — выбрано (по-русски «инсайты» звучит приятно).

Почему Insights:

  • Имеет вес: «AI понял что-то о тебе» — синтезированное наблюдение, не сырые данные.
  • Популярно в health-tech (Apple Health Insights, Levels Insights) — пользователи знают слово.
  • Множественность естественная: «несколько insights о твоём здоровье».
  • Нет конфликта с FHIR resource’ами.

Один Insight = атомарное наблюдение внутри секции; секция содержит один или несколько Insight’ов. Конкретный список из пяти секций и их финальные имена живут в my-health — это продуктовая поверхность, ей решать что и кому показывать.

Слой 4 — per-биомаркер: Biomarker Analyses

Структурный rich-output на каждый биомаркер: интерпретация + reasoning evidence + recommended workup + цитаты. Подаётся в UI или в Insight Synthesis как структурный материал.

Рассматривали:

  • Parameter Analysis — текущее имя в коде. Минус: «parameter» обобщённое программистское слово, не клиническое — пересекается с вопросом «почему биомаркер, а не параметр»: «биомаркер» — точный clinical термин (HbA1c, ALT, eGFR), «parameter» абстрактнее и теряет домен.
  • Biomarker Analysis — выбрано.

Почему Biomarker Analysis:

  • «Biomarker» — точный clinical термин, не overloaded в FHIR.
  • Single biomarker analysis — атомарный кусок, который consumers (UI tile, Insight Synthesizer, downstream agents) комбинируют.

Внутри Biomarker Analysis: Evidence vs Inference

Два разных слоя данных идут на вход в Writer (который потом пишет prose).

Evidence — данные о пациенте (без LLM): что мы реально нашли в FHIR (foundContext), чего не хватает по алгоритмам (missingContext), reference-материал (referenceContext), рекомендованный workup (additionalWorkup). Каждый item с rationale/quotes/source из graph join — то есть это уже знание из графа, не сырые observation’ы; см. biomarker-graph (та самая «отдельная программа», где живёт medical knowledge graph).

Inference — структурированный вывод Reasoner’а (LLM): какие concurrent labs релевантны, mechanistic chain, data gaps, clarifying data items. Audience-agnostic facts, каждый с evidenceRefs обратно на Evidence-items.

Почему два слоя:

  • Evidence — детерминистическое, проверяемое, никаких LLM-галлюцинаций.
  • Inference — LLM-derived, но grounded в Evidence через явные refs.
  • Writer берёт оба и пишет prose. Personalizer добавляет per-item personalized rationale.

Decision page для split’a — health-facts-as-generation-substrate (Variant D).

Альтернативы для Inference-слоя:

  • Knowledge — текущее имя в коде (V2Knowledge). Слишком широкое: Evidence ведь тоже знание.
  • Claims — Variant D doc-терминология («health-claims extractor»). Звучит legal-y, marketing-y.
  • Findings — отвергнуто (конфликт с FHIR-семантикой, см. выше).
  • Reasoning — конфликт с Writer’овым полем reasoning (это prose).
  • Inference — выбрано: точно описывает действие («что LLM выводит из Evidence»), clinical-academic вес («clinical inference»), нет конфликтов.

Биомаркер ≠ Observation

ТерминЧто это
Biomarkerконцепция теста (HbA1c, ALT, eGFR). У одного биомаркера — много observations во времени.
Observationодно измерение в один момент (FHIR Observation).
EnrichedBiomarkerбиомаркер «снапшотированный» одной anchor-observation + Diagnostician plan + Retriever context. Это то, что подаётся в Reasoner / Generator-Normals.

Внутри Phase 1 после dedup keep latest-per-biomarker → каждый биомаркер представлен одной anchor observation. Same-biomarker history (timeline значений) передаётся отдельно в Trends Insight (Phase 3), не в Biomarker Analysis (Phase 2).

Имена фаз пайплайна

ФазаЧто производитDetail page
Phase 1 — Snapshot BuildingSnapshot (curated data)biomarker-actuality-integration
Phase 2 — Biomarker Analysisper-биомаркер Analysesbiomarker-analysis-pipeline
Phase 3 — Insight SynthesisInsights(отдельная страница TBD)
Phase 4 — Persist ReportFHIR write(см. соседние страницы про конкретные resource-decisions)

Actuality classifier — обязательный этап внутри Phase 1, не отдельный пайплайн. Имена фаз — verb+object, чтобы было видно «что делает», а не «что хранит».

UI: My Health (vs Health Status)

Финальная страница пациента — там рендерится последний Health Report.

Рассматривали:

  • Health Status — Васино предложение из heads sync 27 апреля. Естественно по-русски («статус здоровья»). Отвергнуто как одинокое имя в нашем словаре: «status» внутри vocabulary’a больше нигде не используется, и FHIR status enum — universal field на всех ресурсах. Двойная нагрузка.
  • My Health — выбрано (pending team review с Васей).

Почему My Health:

  • Короче и friendly. Patient-facing.
  • Не конфликтует с FHIR status ничем.
  • Согласовано со словарём: пациент видит «My Health» = последний Health Report.

UI-rename pending Васиного okay. До тех пор страница в коде называется health-status, в продуктовых документах — постепенный перевод.

Связано

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

  • Финальные английские имена для трёх Insight-секций (Общее состояние / Чего не хватает / Что обсудить с врачом) — pending team review.
  • Координация UI-rename Health StatusMy Health с Васей.

Архитектурные вопросы про pipeline (history-flow в Reasoner / Personalizer, Patient Writer wiring, унификация двух orchestrator’ов) — на health-report-pipeline. Здесь словарь, не technical state.

Источники