Quartz 4

Структурное отображение медицинских записей

contested
Verified by ildar · yesterday

Created · Updated 4 min read

На каком уровне модели данных живёт ответственность за группировку медицинских записей пациента для отображения. Текущий рендер — плоский неструктурированный список ресурсов (тяжёлые металлы, ЭКГ, социальный анамнез, лабораторные тесты — вперемешку).

Статус

contested — три подхода обсуждаются параллельно. На production — flat list (fhir-observation) плюс первое приближение варианта 1 (группировка по базовым FHIR-категориям).

Контекст

Парсер при конвертации PDF/CDA → FHIR уплощает структуру исходного документа: секции исходного PDF теряются, ресурсы складываются в один общий список. Иллюстративный пример — Hearing tests: в исходном документе четыре парных наблюдения (по два уха × два теста) связаны единой секцией, после парсинга — четыре изолированных Observation в плоской ленте без признаков что они между собой связаны.

То же касается медконтекста — всегда уплощается.

Плоский список — слабое UX-решение: пользователь не различает что перед ним и в каком отношении находятся ресурсы. Это — мотивация переезда на структурированную модель.

Параллельный осложняющий фактор: SNOMED-маппинг сейчас принципиально слабее LOINC. У LOINC закрытый список кодов → LLM выбирает ближайший. У SNOMED список «актуальных» кодов небольшой; если подходящего нет, LLM просят «придумать код из памяти» — качество не валидируется.

Рассматривали

1. Базовые FHIR-категории (Resource.category)

Использовать встроенное поле Resource.category (fhir-resource-categories): Observation → laboratory / vital-signs / imaging / survey / social-history. DocumentReference → LOINC document classes. Каждый ресурс с category по своему value-set’у.

За:

  • Штатный механизм FHIR, без custom extensions.
  • Малые закрытые value-set’ы (9 кодов Observation — простой LLM-маппинг).
  • Категории даются бесплатно — поля уже есть в спецификации.
  • Первое приближение реализовано в production.

Против:

  • Гранулярность недостаточна: все лабы попадают в один bucket laboratory, нет sub-grouping (биохимия / гематология / гормоны).
  • Не сохраняет структуру исходного документа.

2. SNOMED-иерархия

Использовать snomed CT иерархию (Clinical Finding / Observable Entity / Procedure / Substance) как primary taxonomy. Группировка по верхнему уровню иерархии, при необходимости — глубже.

За:

  • Семантическая богатость — покрывает всю мед-онтологию, переиспользуется в графе связей и ассоциациях с заболеваниями.
  • Иерархия даёт переменную глубину группировки в UI.

Против:

  • База непублична — только заявки, membership distribution service, нет свободного доступа к CT.
  • Маппинг сейчас слаб — LLM придумывает коды; нужно строить инфраструктуру как у LOINC (закрытый список + словарный поиск). Построение этой инфраструктуры — отдельный долгосрочный трек.

3. Composition с секциями документа

Сохранять секции исходного PDF/CDA в fhir-composition — оболочках со ссылками на ресурсы. Один Composition на документ, section[] с title / code / entry[] (refs на Observations / Conditions / etc).

За:

  • Сохраняется оригинальная структура документа (Hearing tests / Labs / Vitals — как было в PDF).
  • FHIR-native, Composition специально для этого.
  • Не противоречит вариантам 1 и 2 — Composition обёртка может содержать ресурсы любых категорий и SNOMED-кодов.

Против:

  • Требует изменений в health-report-pipeline (recognize-этап должен извлекать секционную структуру, не уплощать).
  • Не покрывает голые observation-входы (HL7-фиды без структуры документа).
  • Кросс-документальная семантика не решается секциями. Названия секций в разных документах разные («Hearing» / «Аудиометрия» / «ЛОР»), и без нормализованного code-системы (LOINC / SNOMED для section.code) сравнить «эта секция о слухе» между двумя документами не получится. Composition решает intra-document структуру, не inter-document.

К обсуждению

Подходы не взаимоисключающие — Composition хранит исходную структуру, ресурсы внутри помечены FHIR-category, при наличии SNOMED-кода — дополнительная иерархия для cross-document grouping. Поэтому вопрос не «который выбрать», а в каком порядке реализовать следующий шаг поверх уже идущей в production категоризации:

  • Composition как next step — изменения в recognize-этапе, intra-document структура восстанавливается. Cross-document — отдельная задача (нормализация section.code).
  • SNOMED как long-track — лицензирование и инфраструктура маппинга отдельной нитью; результат переиспользуется в biomarker-graph и ассоциациях с заболеваниями.

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

  • Как реализовать Composition корректно — восстанавливать оригинальные секции PDF в section[]? Что делать с документами без явной секционной разметки (HL7-фиды)?
  • Если делаем Composition — какой code-система для section.code, чтобы инвалидировать кросс-документальную проблему «секции называются по-разному»? LOINC document sections / SNOMED Procedure / custom?
  • SNOMED-лицензирование — стоимость и условия доступа к CT прояснить независимо от выбора порядка.
  • Реалистичность сроков SNOMED — построение собственной mapping-инфраструктуры может не уложиться в краткосрочный план.
  • Где живёт UI-state «текущая выбранная группировка» если их несколько — переключатель в шапке, sidebar с видами, persisted preference.

Связано

Graph View