Status: draft
Решение не принято; формулировка только наметилась. Вопрос всплыл в контексте bulk-upload-endpoint — новый endpoint принимает N файлов разом, и реальность B2C-пользователей такова, что один лабораторный отчёт часто приходит как несколько фотографий разных страниц.
Контекст
Пользователь делает фото лабораторного отчёта на телефон — типичный кейс:
- Документ многостраничный (биохимия + лейкоформула + iron panel = 2-3 страницы)
- Пользователь делает по фото на страницу → загружает 3 файла
- Семантически это один анализ, должен стать одним fhir-diagnostic-report / одним TestID-эквивалентом (внутри multi-tenant FHIR)
Альтернативно — пользователь грузит 3 НЕсвязанных файла одним batch’ем (новый анализ + рецепт + выписка). В этом случае каждый файл — отдельная единица.
Нужно понять до recognition, какие из загруженных файлов группируются. От этого зависит:
- сколько
DocumentReferenceсоздать (один per file всегда, но связь между ними) - сколько
DiagnosticReportсоздать (один на группу, не один per file) - какие Observations считаются «одной серией» (визуализация трендов)
- что показать пользователю как «итог одного загрузка»
Открытые вопросы
- Сигналы группировки. EXIF-таймстамп (фото сделаны в одной серии за минуты)? Filename pattern? Похожесть содержимого (тот же header, та же лаборатория, та же дата анализа)? Явное UI-указание пользователя (drag-to-group)? Combinations?
- Когда группировать. На upload (до recognition) — нужны cheap heuristics (timestamp/filename). После recognition — точнее (по lab metadata), но тогда DocumentReference уже созданы и их нужно
merge/link. - Точность vs обратимость. Если auto-group ошибся (два пациента в одной серии) — как пользователь разгруппирует? UI-нужен либо merge-undo, либо confirm-before-group flow.
- Multipage PDF vs N images. PDF приходит уже как один файл — proxy для группы. Images — N файлов. Должна ли группа всегда становиться синтетическим PDF (нормализация), или связь через FHIR-метаданные без склейки бинарей?
Рассматривали (предварительные позиции)
- (a) Не группировать на upload, recognition сам разберётся. Recognition выдаёт metadata (lab name, test date) per файл, post-process склеивает совпадения. Минус: задержка между upload и видимой группой; пользователь успевает запутаться.
- (b) Heuristic auto-group на upload. EXIF + filename + intervals → guess. Минус: false positives (два разных анализа сделаны в один день), нужна undo-UX.
- (c) Явная группа в UI. Drop-zone с pre-grouping (пользователь сам отмечает «эти 3 — один анализ»). Минус: трение, противоречит спирту unified-upload-flow («система сама разбирается»).
- (d) Гибрид. Auto-guess на upload + visible group в UI + одна кнопка «разгруппировать». Минус: сложность.
Что нужно для разрешения
- Реальные данные — сколько % загрузок в практике это multi-image для одного документа vs независимые файлы? (Без статистики любая стратегия — теоретизирование.)
- Прототип UI с тремя вариантами на одинаковом тестовом наборе — какой меньше всего фрустрирует пользователя в edge cases?
- Договор с recognition pipeline — какие metadata он реально извлекает stably (lab name? date? document type?), чтобы оперировать ими в post-process group-detection.
Связано
- bulk-upload-endpoint — endpoint, который принимает N файлов и пока их не группирует
- unified-upload-flow — UX-сторона
- recognition-enrichment-hourglass — где в pipeline это могло бы жить (top half)
- fhir-diagnostic-report — целевой ресурс, для которого нужна группа
- fhir-document-reference — per-file storage; связь между files в группе пока не зафиксирована
Источники
(carry-over: добавить footnote, когда вопрос обсудится в созвоне; пока решение драфт и source — внутренний CriticMarkup-комментарий 2026-05-17)