Архитектурный фрейм всего BloodGPT pipeline. Пользовательский вход (PDF/картинка — неструктурированные байты) сужается до структурированного представления (FHIR R4 — узкое горло), затем расширяется обратно в неструктурированный output (Report PDF/HTML — тексты для человека). Метафора — песочные часы: оба конца широкие и неструктурированные, центр — узкий и структурированный.

Source: дизайн-сессия Ильдара 17 марта 20261, drawio source — hourglass-pipeline-2026-03-17.drawio.

Две фазы

   ▼ Unstructured data  (PDF, image)        — TOP wide

   ╲   RECOGNITION                          — top half narrowing
    ╲    Lab Results Recognition
     ╲   Medical Context Recognition
      ╲  Code Assignment  (LOINC)
       ╲ Range Assignment
        ▼
        Structured data  (FHIR R4)          — WAIST narrow
        ▼
       ╱ ENRICHMENT                         — bottom half widening
      ╱  Interpretation
     ╱   Overview · Panels · Trends
    ╱    Follow-up / Next Steps
   ╱
   ▼ Unstructured data  (Report PDF, HTML)  — BOTTOM wide

Recognition — извлечение из неструктурированного. Превращает байты (PDF/image) в FHIR-ресурсы. Подробности — recognition.

Enrichment — обогащение структурированных данных. Принимает FHIR-факты, выпускает интерпретации, обзоры, follow-up рекомендации, рендерится в финальный отчёт. Подробности — biomarker-analysis-pipeline. Термин устоявшийся; ранее в коде использовался «processing», переименован осознанно.

Почему форма важна

Геометрия песочных часов делает важное архитектурное утверждение: FHIR R4 — единственная узкая точка, через которую проходит всё. Не просто хранилище данных, а обязательный канал между двумя фазами. Любая интеграция/рендерер/новая аудитория цепляется либо к верхнему конусу (новый source recognition), либо к нижнему (новый renderer enrichment) — и не имеет права обходить FHIR-горло.

Структурно это даёт:

  • Single source of truth на уровне фактов. Все downstream-агенты, audience-варианты, экспорты — читают из одного FHIR-store.
  • Compounding inputs — добавление нового source расширяет верхний конус, не трогая нижний. Структурированные источники (HL7v2, JSON) обходят recognition и входят сразу в waist — это симметрия логики, а не противоречие форме.
  • Compounding outputs — добавление новой аудитории (доктор / пациент / страховая / семья) расширяет нижний конус, не трогая верхний. См. health-facts-as-generation-substrate.

Что внутри Recognition (top half)

Шаги от raw bytes к фактам в FHIR:

  • Lab Results Recognition — параметры (имя, value, unit, range) из формализованных таблиц лаборатории
  • Medical Context Recognition — диагнозы, лекарства, аллергии в нарративе документа. Считается частью recognition, не отдельной категорией.
  • Code Assignment (LOINC) — добавление стандартных кодов поверх raw original_name. Семантически это добавление атрибута, не трансформация значения — отсюда название (не «normalization»). См. loinc-harmonization-pipeline.
  • Range Assignment — добавление reference range поверх raw value. Та же логика: добавление атрибута, не «detection». См. reference-ranges.

Что внутри Enrichment (bottom half)

Шаги от FHIR-фактов к текстам:

  • Interpretation — что значит параметр у этого пациента в этом контексте. Diagnostic + Retriever + Generator из biomarker-analysis-pipeline.
  • Overview · Panels · Trends — агрегаты разного scope (тест целиком / панель / временной ряд)
  • Follow-up / Next Steps — рекомендуемые действия, см. fhir-careplan

Внутри enrichment есть дополнительный split между substrate-builder (сухие факты с акцентами) и writer (стиль / язык / аудитория). По песочным часам — финальный fan-out на доктора / пациента / другие аудитории происходит в самом низу нижнего конуса, выше — единый audience-agnostic слой фактов. См. health-facts-as-generation-substrate.2

Привязка к коду

Bulk upload — расширение верхнего конуса как одна точка входа для произвольных unstructured файлов; не возвращает TestID, потому что тест перестаёт быть юнитом вывода (bulk-upload-endpoint, unified-upload-flow).

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

  • Структурированные источники (HL7v2, JSON) обходят recognition и попадают сразу в waist. Как технически: тот же endpoint что и unstructured upload, или отдельный? См. bulk-upload-endpoint — пока endpoint один, но recognition triggered conditionally.
  • Ground truth для recognition (golden dataset) — слишком дорог; используется ручная верификация со скриншотами + Клод double-check. Carry-over: формализовать или принять как permanent state.
  • Symmetry vs asymmetry — recognition сейчас сильно более зрелая phase (RFC-013, fact-based redesign, bounding-box validation), enrichment — ещё в active development (Variant D только что принят). Нужен ли сопоставимый «fact-based» подход в enrichment кроме health-facts-as-generation-substrate?

Связано

Сноски

  1. Сессия ildar/0dfd285d, 2026-03-17 — оригинал концепта «песочных часов» для recognition-enrichment hourglass; 6 итераций drawio-схем.

  2. Сессия ildar/34e93701, 2026-04-24 — продолжение concept-разработки в bottom-half (substrate vs writer split); pipeline-diagrams набор зафиксирован.

  3. Daily + Sprint Review & Planning, 27 апреля 2026 — https://github.com/Realai-plus/meeting-digests/blob/main/data/digest/2026/04/2026-04-27T08%3A00%3A00.000Z_Daily_%2B_Sprint_Review%26Planning_01KPX39F5EMF092HA0PGKSX1FV.md ([Р1] Variant D, [Р4] bulk upload endpoint, [Р6] TS pipeline для narrative→FHIR).

  4. ЧутокПланирования, 27 апреля 2026 — https://github.com/Realai-plus/meeting-digests/blob/main/data/digest/2026/04/2026-04-27T10%3A04%3A11.000Z_%D0%A7%D1%83%D1%82%D0%BE%D0%BA%D0%9F%D0%BB%D0%B0%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_01KQ76AZGHMBNH1RCPTDYSRB4F.md ([Р1] PHI separation refinement).