Quartz 4

Какие типы загружаемых документов поддерживаем

draft
Not verified

4 min read

Полный набор существующих типов описан в uploaded-document-types (16 классов в 4 tier’ах). Эта страница фиксирует подмножество которое мы фактически принимаем и обрабатываем — и что отвечаем на остальное.

Контекст

Юзер может принести что угодно — от CBC-бланка до прививочного паспорта. Без явного решения возможны два неприятных сценария:

  • Принимаем всё, обрабатываем всё — recognition пытается извлечь структурированные данные из рукописного эпикриза или прививочного сертификата → плохое качество, false positives на биомаркеры, юзеру кажется что система работает плохо.
  • Принимаем без сигнала — юзер залил рецепт, ждёт интерпретации, ничего не происходит, не понимает почему.

Решение нужно потому что (а) качество recognition зависит от типа документа, (б) AI-обзор Composition имеет смысл только для лаб-данных, (в) UX-обещание «загрузи и поймём» должно соответствовать реальности.

Позиции

A. Принимаем всё, обрабатываем всё (open ingestion)

Любой документ через /upload → recognition → структурированные данные → AI-summary.

  • ➕ Простой UX, нет gatekeeping
  • ➖ Recognition не справляется с narrative-only документами, выдаёт мусор
  • ➖ AI-summary включает данные, которые AI не предназначен интерпретировать (рецепты, vaccinations)
  • ➖ Юзер не знает что часть данных потерялась

B. Принимаем только Tier 1 (лаб-данные) — текущее поведение

Recognition настроен на extract biomarkers из лаб-отчётов. Всё остальное — out of scope.

  • ➕ Соответствует тому что pipeline реально умеет
  • ➕ Качество recognition высокое в narrow scope
  • ➖ Юзер с эпикризом получит «не распознано» или плохие данные
  • ➖ Не используем clinical narrative который у нас на руках

C. Tier 1 + Tier 2 (lab + clinical narrative)

Принимаем лаб-отчёты и narrative (discharge / consultation / H&P). Recognition разделяет:

  • Lab → биомаркеры в Observation

  • Narrative → Condition / MedicationStatement / extracted facts в medical-context

  • Composite (эпикриз с lab + narrative) → primary Composition + sections с обоими

  • ➕ Покрывает realistic flow «у меня анализы + выписка из больницы»

  • ➕ Medical-context page уже умеет показывать Conditions / Medications

  • ➖ Composite recognition требует prompt-инженерии — pipeline сейчас не классифицирует

  • ➖ Larger surface area для багов

D. Принимаем всё, route per type (gating + routing)

/upload принимает любой документ. Recognition сначала классифицирует тип, потом routing:

  • Tier 1 → текущий pipeline (biomarker extraction → Observations + DR)

  • Tier 2 → narrative pipeline (medical-context extraction → Condition / Med / Procedure)

  • Tier 3 (рецепт / vaccination) → store DocumentReference, structured extraction опционально, AI-summary не запускается

  • Tier 4 (composite) → split per section, route каждую отдельно

  • Unknown → store as DocumentReference только, юзеру сообщаем «документ загружен, автоматическая интерпретация недоступна»

  • ➕ Honest UX — юзер всегда знает что мы умеем сделать с его документом

  • ➕ Каждый tier обрабатывается тем pipeline’ом который для него предназначен

  • ➖ Большая работа: classification step + 3-4 routing branch’а + UI для «загружено но не интерпретировано»

Что нужно для разрешения

  1. Recognition должен уметь классифицировать тип — сейчас не классифицирует, всегда Laboratory report. Это блок-ID для (C) и (D), не для (B).
  2. Решить про Tier 3 — рецепт и vaccination имеют ценность для медконтекста (что юзер принимает / прививки), но не для интерпретации крови. Storing их как Condition / MedicationStatement / Immunization без AI-обзора — defensible, но добавляет surface.
  3. Composite recognition (Tier 4) — открытый вопрос как prompt разделяет sections. Можно отложить до появления реальных эпикризов в production.
  4. Unknown fallback — LOINC 70004-7 "Notes" как generic, или error?

Следствия (зависят от выбора)

При (C) или (D):

  • Recognition prompt должен возвращать document_type и опционально sections[]
  • buildPreliminaryDocumentReference принимает type как параметр, не захардкожен
  • Routing logic в recognize.orchestrator per detected type
  • Medical-context page может показывать новые типы (Immunization, RX) — UI расширяется

При (D) дополнительно:

  • Новый UI-state «документ загружен, не интерпретирован» с объяснением почему
  • BloodTest.status enum расширяется (stored_only или подобное) или introducing другой entity

При (B):

  • Status quo, но нужно явно описать в UX «принимаем лаб-отчёты», добавить hint при upload
  • Не-лаб документы должны явно отбрасываться с понятным сообщением, а не обрабатываться плохо

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

  • Какой tier берём как initial set — все Tier 1 (7 типов) или только generic Lab report (1) для старта?
  • Tier 3 (prescription / vaccination) — отдельный flow ingestion вне /upload или общий?
  • Если принимаем Composite — Composition пишем мы или recognition выдаёт sections и orchestrator собирает?
  • Multi-language поддержка типов (русские эпикризы, английские consult notes) — recognition должен быть language-aware при classification.
  • DocumentReference.category — фиксируем ли широкие категории (laboratory / clinical-note / administrative) параллельно с specific type?

Связано

Источники

Источники: 1.

Сноски

  1. LOINC Document Ontology, accessed 2026-05-17, https://loinc.org/document-ontology/. ↩

Graph View

Backlinks