Интероперабельность медданных: почему один биомаркер — это не один код

Эта статья — про то, как я проектировал референсную архитектуру для приведения лабораторных данных к LOINC (Logical Observation Identifiers Names and Codes — международный справочник кодов лабораторных и клинических показателей) и UCUM (Unified Code for Units of Measure — стандарт машиночитаемого кодирования единиц измерения), и что понял по дороге.

Сразу оговорюсь: это архитектура на бумаге — ADR, схемы и разобранные примеры в репозитории, а не развёрнутый в проде сервис. Боевой нагрузкой пока не проверена.

Все решают одну проблему заново

В каждой лаборатории один и тот же биомаркер пишут по-своему. Вот реальная цепочка названий для одного-единственного фермента — аспартатаминотрансферазы:

АсАТ · AST · АСТ · аспартатаминотрансфераза · аспартат-аминотрансфераза · глутамат-оксалоацетат-трансаминаза · SGOT · СГОТ

Всё это — один и тот же аналит (то, что измеряют в пробе, — конкретное вещество или показатель). Пока данные живут внутри одной системы, это не проблема: справочник знает свои синонимы. Проблема появляется на границе — когда данные нужно обменять между лабораториями, свести в регистр, отдать в аналитику. Тогда выясняется, что «свой справочник» каждого не стыкуется ни с чьим другим.

Естественная реакция инженера — построить граф синонимов и схлопнуть весь этот список в один код. Я сам так думал. И это работает ровно наполовину.

Почему «список синонимов → один код» — это ловушка

LOINC-код — это не «название анализа». Это полностью специфицированная комбинация шести осей:

И вот ключевой момент: список синонимов выше схлопывается только по одной оси — Component (что за аналит). Но тот же AST в сыворотке и в плазме — это разные коды (ось System). С пиридоксальфосфатом и без — разные коды (ось Method). Количественный и качественный результат — разные коды (ось Scale).

То есть граф синонимов решает необходимую, но недостаточную часть задачи. Он канонизирует имя. А код требует ещё и обстоятельств: чем измеряли, в каком биоматериале, в какой размерности.

LOINC отвечает на «что», UCUM — на «сколько»

Здесь меня долго сбивала одна неточность: казалось, что раз есть LOINC, то единица измерения уже зашита в код, и UCUM избыточен. Это не так.

LOINC задаёт размерность (через ось Property): «это масс-концентрация» или «это молярная концентрация». Но он не говорит, отчиталась ли лаборатория в mg/dL, g/L или mcg/mL — а это всё одна размерность, но разные числа. Реальная единица приходит вместе с данными, не из кода.

Они ортогональны, и нужны оба. Даже внутри одного LOINC-кода единицы могут различаться: лаборатория А шлёт глюкозу в mg/dL, лаборатория Б — ту же самую в g/L. Понятие совпало, числа — нет. Усреднишь по коду без приведения единиц — получишь мусор. Вот тут и работает UCUM: приводит mg/dL → g/L детерминированно, потому что это одна размерность и коэффициент не зависит от вещества.

А вот mg/dL → mmol/L (масса → молярность) — это смена размерности, и она требует молярной массы конкретного вещества. UCUM этого не делает и делать не должен — он ничего не знает про вещества. Это та же самая стена, что ось Property в LOINC, просто с другой стороны: масс-код и молярный код — это разные коды, и переход между ними — отдельная задача с учётом вещества.

Зачем такая дотошность: RWE и OMOP

В этот момент возникает законный вопрос: не избыточное ли это усложнение? Ответ зависит от того, зачем вы нормализуете данные.

Если цель — просто зарегистрировать факт («тест на глюкозу назначался»), посчитать частоты или обменяться понятием, то хватит и одной LOINC-нормализации. UCUM здесь ничего не добавляет. То же для качественных результатов («положительно / отрицательно») — там числовой единицы нет вовсе.

Но если цель — аналитика на уровне значений, то есть считать по самим значениям (динамика, сравнение с референсными интервалами, когорты для RWE, фичи для ML), то картина другая. Real-world evidence (RWE — доказательства из данных реальной клинической практики, а не из клинических испытаний) живёт на объединении данных из десятков источников, и здесь критичны две вещи:

• Сопоставимость — глюкоза из лаборатории А и из лаборатории Б должны быть одной и той же сущностью, иначе их нельзя складывать. LOINC даёт стабильный ключ.

• Защита от ложной агрегации — нельзя тихо смешать сывороточную глюкозу с мочевой или активность AST «с P-5’-P» и «без». Оси не дают этому случиться молча.

И это не абстракция. OMOP CDM (Common Data Model — стандартная модель данных для наблюдательных исследований), на которой стоит весь инструментарий OHDSI (Observational Health Data Sciences and Informatics — международное сообщество и набор инструментов с открытым исходным кодом поверх OMOP), спроектирована буквально под эту пару. В таблице MEASUREMENT:

• measurement_concept_id ← LOINC (что измерено, со всеми осями),

• unit_concept_id + value_as_number ← UCUM (единица + число),

• value_as_concept_id ← качественный результат (ось Scale у LOINC).

То есть OMOP-таблица — это почти один-в-один LOINC (оси) + UCUM (единица). Это не совпадение: модель строилась вокруг этих стандартов. А значит, слой нормализации сырое имя + контекст → LOINC + канон UCUM — это, по сути, ETL-дверь (extract-transform-load — извлечение, преобразование и загрузка данных) в OMOP. Без него таблица MEASUREMENT заполняется мусором.

Как это внедрить, не переписывая всё

Самый частый страх при слове «стандартизация»: «значит, надо снести наш справочник и собрать всё заново». Нет. Это классический паттерн strangler fig («удушающий плющ») — новый слой обрастает старую систему по краям, ничего не ломая.

Ключевой сдвиг: LOINC/UCUM не заменяет ваш внутренний справочник. Он садится слоем выше как канонический интерлингва (промежуточный язык-посредник, через который сопоставляются разные системы). Ваш справочник остаётся локальным словарём, а LOINC — тем, с чем он сопоставляется для обмена наружу. Те самые кропотливо собранные синонимы не выбрасываются — они становятся входным слоем, который питает нормализацию. Граф синонимов ALT — это не конкурент резолверу, это его поставщик.

Отсюда же модель уровней зрелости: можно войти на минимальном уровне (ключевые биомаркеры, только новые записи, базовый код), а старые данные оставить в старой форме и пересопоставить позже — по желанию, не принудительно. Внедрение становится постепенным: сопоставление только новых записей, по желанию — дозаполнение старых данных, подъём по уровням точности по мере готовности.

Почему не просто отдать всё языковой модели

Здесь возникает резонное возражение: зачем весь этот аппарат осей, версий и правил, если современная языковая модель и так «поймёт», что АлАТ — это ALT? Ответ — не «модель плохая», а «у неё в этой архитектуре точное и узкое место, и это не место того, кто выдаёт итоговый код».

Где модель незаменима — это распознавание имени аналита: схлопнуть «АсАТ / AST / SGOT / глутамат-оксалоацетат-трансаминаза» в одну сущность. Здесь доменная модель — или биомедицинские эмбеддинги (числовые векторы, кодирующие смысл: близкие по смыслу названия близки и в пространстве) класса BioLORD / SapBERT — бьёт любой рукописный словарь синонимов. То есть модель нормализует имя (ось Component) и поднимает кандидатов-кодов с оценкой. Остальные оси, от которых и зависит конкретный код (System, Method, Scale, Property), приходят отдельно и явно из контекста и применяются детерминированными правилами приоритета — а не угадываются. Поэтому важные обстоятельства не теряются: модель за них просто не отвечает. И итоговый код она тоже не выдаёт — его выбирает детерминированный слой: правила приоритета, проверка кода по снимку справочника, аудит.

Причина такого разделения — два свойства, особенно опасные в медицине:

• Модель угадывает, а не гарантирует. Один и тот же вход даёт разные коды в разных прогонах, а в придачу модель охотно выдаст правдоподобный, но несуществующий код. Для RWE это тихий яд: дрейф сопоставления превращается в дрейф данных. Поэтому код проверяется на формат и на существование по снимку справочника, а не принимается на веру.

• Нет воспроизводимости и учёта версий из коробки. Модель не объяснит, почему выбран именно этот код, и не знает, что он устарел и заменён в текущей версии. Это держат слой аудита и слой версионирования — на них и стоят воспроизводимость и разбор.

А какая именно модель стоит в резолвере — деталь реализации: архитектура держит его как заменяемый слой и от конкретной модели не зависит.

Честно про путь

И последнее, личное.

Я спроектировал эту архитектуру раньше, чем разобрался в LOINC и UCUM до уровня шести осей. Сначала появились решения и компромиссы, и только потом, докапываясь до деталей стандарта, я заметил, что многие из них совпали с тем, как устроены сами стандарты. Выглядит как «надо было сначала изучить, потом делать» — но, кажется, порядок был правильный.

Для меня проектирование было способом разобраться, а не итогом: грубая модель, столкновение с реальностью, уточнение. Каждый новый факт про LOINC находил, куда лечь, потому что под него уже был готов слот — и запоминался лучше, чем если бы я просто прочитал спецификацию.

Поэтому статья и репозиторий — скорее попытка показать ход мысли, чем готовый рецепт. Залезут пара человек в репозиторий, покрутят сами — хорошо. Нет — мне это всё равно уже помогло разобраться.

Ссылки

Репозиторий: https://github.com/alarent/loinc-ucum-reference-architecture

Разбор решений (ADR): каталог docs/adr/ в репозитории