Quartz 4

Единый drop-zone для загрузки — без разделения на «тесты» и «медконтекст»

active
Not verified

5 min read

Все файлы пользователь загружает в один drop-zone, без отдельных полей для «тестов», «медконтекста», «медицинских заметок». Система автоматически определяет тип каждого файла (анализ / выписка / рецепт / imaging report) и структурирует данные. Применяется к общей технологии распознавания — она лежит и за FHIR Gravity (B2B middleware), и за B2C-порталом, поэтому решение работает в обоих случаях.

API-сторона — отдельный endpoint, существующий B2B контракт неизменен — bulk-upload-endpoint.

Контекст

Текущий интерфейс заставляет пользователя выбирать куда грузить файл — есть отдельные поля «тесты», «medical context», «medical notes». Это создаёт значительный frication: даже мотивированные, технически продвинутые пользователи не справляются с задачей без значительной живой помощи1. Наблюдённые failure modes:

  • Загрузка нескольких файлов как одного отчёта без получения трендов
  • Непонимание разницы между «тесты» и «медконтекст»
  • Вставка медконтекста в поле «Medical Notes», которое раздувается на весь экран

«Это было удивительное наблюдение за поведением. Максимально мотивированный пользователь, который вообще не справился с задачей.»1

Если мотивированный пользователь не справляется — массовый сегмент (обычные пациенты / врачи) не справится тем более. Сценарий «человек, который хочет загрузить и не может» — конец воронки adoption.

Выбрали: единый drop-zone, AI определяет тип

Пользователь грузит все файлы в одно место. Backend сам определяет тип каждого, маршрутизирует в подходящий recognition path, структурирует в FHIR. Вопрос «куда загружать» исчезает на уровне UX.

Это продолжение архитектурного направления analytical routing2 — определение типа документа на загрузке. К 2026 эта функция стала частью FHIR Gravity middleware.

Сопутствующие UX-изменения в том же направлении:

  • «Тесты» → «мои файлы» / «мои документы». Текущий термин «тесты» не покрывает выписки / рецепты / imaging, и массовому пользователю он непонятен. Имя «my health» в этой раздел не идёт — оно занято под отдельную концепцию (отчёты по здоровью, см. health-report-vision).
  • Автоматическая группировка файлов на стороне backend (по дате, типу, источнику). Группировка — не задача пользователя. Конкретные сигналы и стратегия не зафиксированы — см. multi-image-file-grouping (draft).
  • Lazy generation отчётов — генерируется только последний / актуальный, исторические — по запросу. Снижает время ожидания.

UI-концепт «file manager»

Замена текущего «java-style» загрузчика3:

  • Drop-зона в центре с крупным текстом: «грузи сюда любые медицинские файлы — PDF, изображения, анализы, справки, рецепты»
  • Список загруженных файлов рядом / под drop-зоной; пользователь видит весь набор и может добавить ещё
  • Раздельные шаги загрузка → обработка: пользователь сначала набирает все файлы, потом по кнопке «Дальше» стартует recognition. Снимает confusion и даёт контроль
  • Lazy generation: тренды / overview конкретного файла генерируются при открытии, не batch’ем на upload
  • Один и тот же flow на мобайле и десктопе
  • Переименование приложения с «BloodGPT» — текущее название создаёт впечатление, что продукт только про кровь, а реальный scope шире (любые медицинские документы). Конкретное новое имя ещё не выбрано — см. project-rename (draft).

Почему

  • Несправляющиеся мотивированные пользователи = конец воронки adoption. Без unified upload даже early-adopter retention теряется.
  • AI-routing технически готов через FHIR Gravity (см. fhir-gravity) — recognition pipeline уже определяет тип документа. Перенос на пользовательский UX — продуктовая реализация уже-существующей capability.
  • Соответствует позиционированию «прибор, не рекомендация» (см. medical-as-instrument-not-recommendation) — прибор должен «просто работать», не задавать вопросов о routing.
  • Уход от тестов как нативной модели — пользователь думает в категориях «моё здоровье», «мой файл», не «лабораторный тест №3» (см. use-cases).

Связь с верхней частью «песочных часов»

Решение относится к верхнему конусу recognition-enrichment-hourglass (input side — recognition): расширение типов unstructured input, который мы принимаем, и точки входа в pipeline. Через эту же связь пересекается с health-report-vision (paradigm shift тест-центрик → snapshot-центрик):

  • Раньше: каждый файл → отдельный BloodTest → отдельный отчёт. Юнит вывода = тест.
  • Сейчас: единый drop-zone → всё сохраняется в FHIR-базу → генерация snapshot только для последнего / актуального состояния (или summary в контексте последнего).

То есть тест перестаёт быть юнитом вывода. Output — point-in-time snapshot пациента, привязанный к дате. Загруженные файлы остаются в FHIR полностью как данные; вопрос, какие именно события / правила запускают snapshot generation (триггеры), пока не зафиксирован. Что было exploratory paradigm shift — получило конкретный production-trigger в части unified upload.

Следствия

  • «FHIR Gravity» middleware — обязательная часть upload pipeline (не опциональная). Без неё единый drop-zone технически невозможен. «FHIR Gravity» — маркетинговое имя для backend-распознавания: превращение unstructured входа (PDF / image / текст) в FHIR-структуры. Технически это уже-существующий recognition pipeline, упакованный под brand.
  • Recognition должен корректно определять не-blood-test файлы (медицинские выписки, prescriptions, imaging reports) — расширение coverage за пределы blood tests.
  • Поле «Medical Notes» убирается из UI — содержимое медконтекста автоматически извлекается из любого загруженного файла или текстового ввода и хранится в FHIR.
  • Grouping логика должна жить на backend (по дате, типу, источнику) — UI показывает сгруппированный результат, не просит пользователя группировать. Как именно реализовать — открытый вопрос, см. multi-image-file-grouping (draft).

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

  • Proactive data clarification — текущая модель «спросить про беременность на каждый загруз» наивна; целевая — agent на этапе generation определяет нехватку данных и формирует follow-up. Это глубокая тема, вынесена в proactive-data-clarification (draft).
  • Группировка multi-image upload — как backend понимает, что N фото = один документ. Отдельная decision-страница (draft): multi-image-file-grouping.

Связано

  • bulk-upload-endpoint — API-сторона того же решения (separate endpoint, B2B контракт неизменен)
  • recognition-enrichment-hourglass — место в архитектуре (расширение верхнего конуса песочных часов)
  • health-report-vision — теоретическая основа paradigm shift (тест-центрик → snapshot-центрик)
  • fhir-gravity — маркетинговое имя для backend recognition (unstructured → FHIR), на котором этот flow технически держится
  • use-cases — пересечение с B2C self-service сценарием
  • medical-as-instrument-not-recommendation — позиционирование как прибор требует frictionless UX
  • recognition — расширение recognition coverage за пределы blood tests

Сноски

  1. «Про FDA?», 2026-04-23, https://github.com/Realai-plus/meeting-digests/blob/main/data/digest/2026/04/2026-04-23T11%3A58%3A47.000Z_Про_FDA%3F_01KPX39YPADYSZX7281KJM0Y0F.md — Георгий не справился с задачей (Н1); переименование «тесты» → «my health» (Р1); только последний отчёт (Р2); единый загрузчик в рамках FIRE (Р4); medical notes → FHIR (О1); smart-questions (О2). ↩ ↩2

  2. «Daily StandUp», 2025-12-17, https://github.com/Realai-plus/meeting-digests/blob/main/data/digest/2025/12/2025-12-17T09%3A00%3A00.000Z_Daily_StandUp_01KC94FNRQQXT2363F4MK7T9RA.md — архитектурный шаг analytical routing: определение типа документа на загрузке (Р1). ↩

  3. «Daily + Sprint Review & Planning», 2026-04-27, 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 — file manager UI (Р2); раздельные шаги загрузки/обработки (Р3); Ильдар на конец недели (Э2). ↩

Graph View

Backlinks