Pipeline, который превращает неструктурированный входной документ (PDF, изображение) в структурированный набор параметров для downstream-этапов (loinc-harmonization-pipeline, reference-ranges, FHIR text-generation).
Структурированные источники (HL7, JSON) идут отдельным путём — там данные уже в готовом формате, recognition не нужен. См. hl7-input-pipeline.
Что делает
- Классификация документа: лабораторный анализ vs медконтекст vs нерелевантное (фото еды, чек) vs sample/demo (отклоняется)
- Извлечение параметров (имя, value, unit, range)
- Извлечение медконтекста (диагнозы, лекарства) если есть
- Multi-page handling (один документ может содержать N тестов на разных датах + страницы контекста)
Один документ может быть смешанным: только параметры / параметры + контекст / только контекст.
Текущий pipeline
В Никитиной integration основной prompt — recognize_image_to_fhir (заменяет legacy recognize_gpt). PDF конвертится в изображения (pure PDF не работает). Главный принцип:
«You are an OCR engine, NOT a doctor. Visual Evidence > Medical Knowledge.»
Прямая визуальная транскрипция, не медицинская валидация. Если range выглядит “неправильно медицински” — копировать как напечатано.
Document classification — primary lab report выделяется по комбинации: формальная таблица Parameter | Value | Unit | Range, страница посвящена результатам (не embedded в narrative). Sample/demo фильтр — повторяющиеся подозрительные значения (1234, 5678), нереалистичные имена, шаблоны.
Извлекаемые поля per parameter:
original_name,original_value,original_unit,original_range— visual transcriptionvalue,unit,range— нормализованныеoriginal_status(RFC-013, proposed) — визуальный маркер от лабы (H/L/↑/↓/red marker/etc.) → enumHIGH|LOW|CRITICAL_HIGH|CRITICAL_LOW|ABNORMAL|null
original_status — значимое расширение: лаба уже делает работу по интерпретации (ставит ↑ на превышение). Игнорировать это — потеря источника валидации (см. reference-ranges и lab-status-vs-derived-interpretation).
Practical tips (Никита’s research, Apr 6)
temperature: 0.0для extraction-задач- JSON-Prompt вместо JSON-Schema — разница до 11 п.п. в точности
thinking: medium— выше обычно не даёт прироста качества- Gemini Flash для recognize, не Pro — Flash дистиллирован из Pro и не overthinks; на OmniDocBench даёт самый низкий edit distance среди frontier моделей. Pro tends to overthink на простых extraction tasks (~31× больше токенов на простых задачах). См. gemini-flash-vs-pro-allocation — model split.
Redesign — fact-based подход (в работе)
Активная смена парадигмы: вместо single-prompt OCR-extraction → fact-based подход (промежуточное представление как набор fact’ов с position/source). Уменьшает path-зависимость, помогает с multi-date / multi-page mixed content / bounding-box validation.
Конкретика:
- Прототип Ильдара (BG-1059): ветка
feat/universal-bbox-editor→ rebasedfeat/fact-extraction-rebase. 5 коммитов (Mar 29 — Apr 1) вapps/benchmark+packages/ocr-core. Sessions:c28bb497(Apr 9-10 implementation),1d3c504b(Apr 21 rebase). - Версия Никиты: ветка
feat/image-recognize-to-fhir(active Apr 22-23, 13+ коммитов). Unified image-based pipeline with CoT prompt + multimodal narrative → FHIR conversion + multi-date documents (per-param test_date, DocumentReference per date) + date-attribution rules / cross-page dedup + two-phase FHIR save. - Сейчас интегрируется Никитина версия в production pipeline (Артур больше не lead на этой задаче).
См. fact-based-recognition (active, integration в работе).
Bounding-box validation interface (отдельный track)
Ильдар исследовал возможность recognition output с bounding boxes (координаты на странице где найден параметр) и достиг успеха — создал валидационный интерфейс. Это даёт:
- Visual link между PDF и распознанным параметром (для review)
- Ground truth для evaluation (corner-case detection: “что-то не там распознано”)
См. bounding-box-validation (placeholder для отдельного описания).
Multi-date / multi-page PDF — частично решается через fact-based
Лаба может прислать PDF где результаты разных дат в одном документе. Текущий pre-fact-based pipeline ожидает один тест на файл; multi-date документы — данные смешиваются или теряются.
Этот кейс меняется при переходе на fact-based: каждый fact несёт свой context (включая дату). Мульти-датный документ становится множеством fact’ов с разными датами вместо потерянной информации.
История подходов до fact-based:
- Промпт-улучшения (Apr 1, изначально Артур; теперь Никита)
- Идеи: biomarker-based recognition, аннотации страниц, Markdown+ROM
- “SQL-подход” Васи (Apr 1 daily, [Н6] в digest) — это была метафора, не реальный SQL. Ильдар развивал эту идею как промежуточный variant (“хранить через текст”), что привело к fact-based.
OCR validation flow (RFC-012) — идея, не deployed
RFC-012 описывает human-in-the-loop систему контроля качества recognition: приоритизированная очередь параметров для проверки, QA-роли, feedback-loop для улучшения prompt.
Status: идея для будущего, никогда не было в production. RFC написан, реализация откладывалась. Bounding-box interface (см. выше) — частично делает это в другом виде (visual review вместо text-queue).
Открытые вопросы
- Текущий status fact-based integration — где Никита, что blocked, какой timeline
original_status(RFC-013) implementation status — задеплоено / в работе / предлагается- Cyprus lab quirks (греческое+английское смешивание, conflicting indicators) — частично решается fact-based, частично остаётся (см. reference-ranges failure modes)
- Текущая prompt-version и модель
recognize_gpt— verify актуальное состояние
Связанные решения
- fact-based-recognition — redesign direction (active, integration in progress)
- gemini-flash-vs-pro-allocation — model allocation per prompt (active)
- lab-status-vs-derived-interpretation — trust lab status; recognition должен передавать
original_statusдля downstream - doctor-patient-prompts-not-fork — adjacent (downstream FHIR text-pipeline use cases)
Связано
- loinc-harmonization-pipeline — downstream от recognition (raw lab name → LOINC mapping)
- reference-ranges — downstream (range из document)
- fhir-modeling-ai-content — куда recognition output идёт в FHIR
- hl7-input-pipeline — структурированный alt path (recognition НЕ нужен — данные готовы)
- bounding-box-validation — separate track, Ильдар’s interface для visual review
- custom-reference-ranges — пересекается через lab catalog upload
Источники
Источники: 1.
Сноски
-
Multi-date / Васина SQL-метафора discussion: 2026-04-01 transcript “Портирование LOINC” ([Н6] / [О4]), accessed 2026-05-17, https://github.com/Realai-plus/meeting-digests/blob/main/data/digest/2026/04/2026-04-01T11%3A07%3A08.000Z_портирование_loinc_01KN4BKJSP8PSGBSN23VFZ25M0.md. ↩