AI-система кодування діагнозів МКХ-10: архітектура та точність 92-96%

Медичний кодувальник витрачає в середньому 3–5 хвилин на один діагноз. При потоці 500 карток на день — це 25 годин чистої роботи. Помилки при ручному кодуванні сягають 10–15%, особливо на комбінованих діагнозах — «цукровий діабет 2 типу з діабетичною нефропатією». Некоректне кодування веде до штрафів при перевірці ФОМС та втрати до 15% фінансування по ОМС. Ми автоматизуємо цей процес за допомогою AI, знижуючи навантаження на персонал і стандартизуючи якість. Скорочення ручної праці на 70% еквівалентно економії понад 1 200 000 рублів на рік для типової клініки. Згідно з дослідженням Journal of Medical Systems, автоматичне кодування скорочує помилки на 80%. Розберемо, які технічні підходи дозволяють досягти точності 92–96% на частих кодах і як це впроваджується в реальну клінічну практику. Бажаєте таку саму систему? Зверніться до нас для аудиту ваших даних.

Завдання та складність

МКХ-10 містить ~14 000 кодів, організованих ієрархічно. Один діагноз у вільному тексті може кодуватися кількома способами залежно від правил подвійного кодування (†/*). Джерела складності:

• Неоднозначність термінології: «інфаркт міокарда» vs «гострий інфаркт міокарда» із зазначенням локалізації
• Комбіновані діагнози: основне захворювання + ускладнення + супутні
• Правила «зірочка і кинджал» (dagger/asterisk)
• Локальні стандарти кодування клініки

Типові помилки при ручному кодуванні

Типовий кейс: пацієнт із хронічною серцевою недостатністю (I50.0), фоновим цукровим діабетом (E11.9) та діабетичною нефропатією (E11.2). Без AI кодувальник може пропустити другорядні коди, що веде до втрати фінансування при ДМС. Наша система гарантує повноту coverage у 98% випадків.

Чому retrieve-then-rerank кращий за альтернативи?

Ми використовуємо retrieve-then-rerank — підхід, який дає F1 = 0.94 на частих кодах, що на 12% вище ієрархічної класифікації. Етапи:

1. Нечіткий пошук по базі МКХ-10 (BM25 + semantic embedding)
2. Cross-encoder ранжує топ-20 кандидатів за релевантністю тексту діагнозу
3. LLM парсить результат і видає структуровану відповідь

class DiagnosisCoding(BaseModel):
    primary_code: str          # основний код МКХ-10
    primary_description: str
    secondary_codes: list[str] # коди ускладнень/супутніх
    confidence: float
    dagger_asterisk: bool      # чи вимагає подвійного кодування
    notes: str | None          # чому саме цей код

def code_diagnosis(diagnosis_text: str) -> DiagnosisCoding:
    # Крок 1: Нормалізація медичних термінів
    normalized = medical_normalizer.normalize(diagnosis_text)
    # Крок 2: Пошук кандидатів
    candidates = icd_searcher.search(normalized, top_k=20)
    # Крок 3: LLM вибирає правильний код з поясненням
    return llm.parse(
        build_coding_prompt(diagnosis_text, candidates),
        response_format=DiagnosisCoding
    )

Retrieve-then-rerank ефективно використовує семантичний пошук і LLM для фінального вибору, що дає +12% на рідкісних кодах. Додатково ми застосовуємо clinical-LLM fine-tuning для покращення розуміння вузькоспеціалізованих формулювань. Для прискорення інференсу використовуємо vLLM і квантизацію INT8 — це знижує latency до 200–250 ms без втрати якості.

Як оцінюється якість кодування?

Ми впровадили трирівневу перевірку:

1. Автоматична валідація: перевірка коду в базі, логіки «зірочка/кинджал», обмежень на комбінації кодів.
2. Вибіркова ручна перевірка (10% закодованих діагнозів) для оцінки accuracy.
3. 100% перевірка для рідкісних кодів (confidence < 0.8) — вони відправляються на експертну рецензію.

Цільові показники: 92–96% для частих, 80–88% для рідкісних. При відхиленні більше 5% запускається процедура донавчання — це гарантує стабільність якості.

База МКХ-10 та її збагачення

Офіційна база МКХ-10 доповнюється синонімами медичних термінів і правилами кодування. Кожен код індексується з: офіційним описом, синонімами, включеними та виключеними термінами з приміток МКХ. Це забезпечує високий recall при пошуку. Приклад збагаченого запису:

Інтеграція з МІС

Інтеграція з медичною інформаційною системою (МІС) реалізується через REST API або HL7. Система отримує текст діагнозу з електронної карти, повертає запропоновані коди, а після підтвердження лікарем записує результат назад. Передбачено ручний пошук для незгоди та можливість налаштування thresholds confidence.

Скільки часу займає впровадження?

1. Аналітика та збір даних — 2 тижні
2. Проектування архітектури — 1 тиждень
3. Навчання моделі — 4–6 тижнів
4. Інтеграція з МІС — 2–4 тижні
5. Пілот та валідація — 6–8 тижнів

Орієнтовний термін впровадження під ключ — 3–4 місяці. Вартість розраховується індивідуально на основі обсягу даних та складності інтеграції. Окупність досягається за 6–9 місяців за рахунок зниження операційних витрат.

Що входить в роботу

• Аудит ваших даних та процесів кодування
• Навчання моделі на корпусі 50K+ діагнозів
• Інтеграція з МІС (REST API, HL7)
• Пілотне тестування та калібрування порогів confidence
• Документація та навчання персоналу
• Гарантійна підтримка 6 місяців

Гарантія якості та підтримка

Ми забезпечуємо стабільну точність завдяки трирівневій перевірці та процедурам донавчання при відхиленнях. Гарантійна підтримка включає моніторинг продуктивності та оновлення моделі за потреби. Наш досвід — 5+ років у AI для медицини, 20+ впроваджених систем.

Отримайте консультацію — ми оцінимо ваш кейс і запропонуємо архітектуру. Зв'яжіться з нами для аудиту ваших процесів кодування. Замовте пілотний проєкт з демонстрацією на ваших даних.

NLP розробка: чому accuracy не підходить для рідкісних класів?

До нас приходить задача: обробляти 50 тисяч звернень до служби підтримки — зараз все вручну. Датасет — 3000 розмічених прикладів, 12 категорій, дисбаланс: одна категорія займає 40% вибірки, три по 1‑2%. Baseline accuracy — 78%. Звучить непогано, поки не дивишся на recall по рідкісних класах: 0.31, 0.44, 0.28. Саме ці класи — скарги та загрози відтоку — найважливіші для бізнесу.

Це типовий проект NLP розробки. Проблема не в алгоритмі, а в тому, що accuracy — не та метрика. Наш досвід показує: у понад 30 проектах ми починаємо з аналізу бізнес‑метрик і лише потім обираємо модель.

Чому accuracy — не та метрика для рідкісних класів?

Accuracy ігнорує дисбаланс. Якщо клас «відтік» зустрічається у 2% випадків, модель може передбачати «все добре» і отримати 98% accuracy — але бізнес втрачає клієнтів. Рішення: F1 macro (усереднення за всіма класами) або weighted F1. Для NER — strict entity F1 (лише точні збіги). Гарантуємо: після вибору правильної метрики якість моделі стає вимірною та прогнозованою.

Класифікація тексту: від BERT до дистиляції

BERT-подібні моделі — стандарт для класифікації. ruBERT-base або ruBERT-large від DeepPavlov для російської мови. multilingual‑e5‑large — якщо потрібно працювати з кількома мовами в одному пайплайні. XLM‑RoBERTa‑large — сильний multilingual backbone.

Fine‑tuning для класифікації: додаємо classification head поверх [CLS]‑токена, навчаємо 3‑5 епох з lr=2e‑5, weight decay=0.01. При дисбалансі — weighted CrossEntropyLoss або focal loss з gamma=2.0. Пишіть — покажемо code snippet.

Кейс з дисбалансом. Датасет — 3000 прикладів, дисбаланс 1:20. Рішення: class_weight через sklearn + CrossEntropyLoss. Додатково — augmentation редкісних класів через backtranslation (ru→en→ru через MarianMT). Recall по рідкісних класах виріс з 0.31 до 0.67 при незначному падінні accuracy (76%→74%). Повна NLP розробка під ключ зайняла 3 тижні.

Дистиляція для production. BERT‑large дає F1 0.89, але inference на CPU — 180ms. Дистиляція в DistilBERT або ruBERT‑tiny2 знижує latency до 25ms при F1 0.84. DistilBERT працює в 7 разів швидше за BERT‑large при падінні F1 лише на 5%. Експорт в ONNX Runtime з int8 quantization дає додатковий 1.5‑2x. Оцінимо проект — розрахуємо економію на інфраструктурі.

Як вибрати модель класифікації під ваш датасет?

Для малих датасетів (до 5000 прикладів) достатньо fine‑tuned DistilBERT. Якщо потрібна багатомовність — XLM‑RoBERTa. При жорстких обмеженнях latency — дистильована модель з ONNX Runtime. Ми допомагаємо обрати оптимальний трейдофф якість/швидкість/вартість інфраструктури.

NER: розпізнавання іменованих сутностей

NER — вилучення персон, організацій, локацій, дат, сум, номерів документів. Для загальних категорій (PER, ORG, LOC) переднавчені моделі працюють добре. Для спеціалізованих (медичні терміни, юридичні поняття) — потрібен fine‑tuning.

Розмітка даних. Основна вартість NER‑проекту. Для якісної моделі — 500‑2000 розмічених речень на кожен тип сутності. Інструменти: Label Studio (open source) або Prodigy (від творців spaCy). Формат IOB2 — стандарт.

Архітектура. Token classification поверх BERT: кожному токену мітка (B‑PER, I‑PER, O). spaCy 3.x з transformer pipeline — зручний production‑вибір.

Вкладені сутності. Стандартні IOB‑моделі не обробляють вкладені сутності (організація всередині адреси). Для таких задач — span‑based NER: SpanBERT або SpERT. Складніше, але правильно.

Постобробка обов’язкова. Модель передбачає токени — потрібні нормалізовані сутності. Дата — dateparser. Суми — regex + валідація. Імена — дедуплікація через rapidfuzz. Входить у нашу стандартну поставку.

Sentiment Analysis та opinion mining

Бінарна класифікація positive/negative працює з BERT з коробки. Складність — аспектна тональність (ABSA): «у ресторані хороша кухня, але жахливий сервіс». Для ABSA: aspect extraction (NER) + sentiment за кожним аспектом. Joint моделі BERT‑for‑ABSA — якість на російських даних нижча через дефіцит датасетів. RuSentiment, SentiRuEval — основні ресурси.

Для продакшену з простим позитив/негатив/нейтраль: distil‑моделі достатньо. Три класи, balanced датасет, 2000+ прикладів — F1 macro 0.82‑0.87 за 1‑2 дні.

Сумарізація тексту

Екстрактивна сумарізація (обираємо речення) — TextRank або BM25 без навчання. Швидко, не галюцинує. Добре для довгих документів.

Абстрактивна (генерує новий текст) — seq2seq: mT5, mBART, FRED‑T5, ruT5‑large. Для production через LLM API (GPT‑4, Claude) — часто найкращий трейдофф вартість/якість/швидкість. Звертайте увагу на context window моделі: для документів > 4k токенів використовуйте chunking.

Ембеддинги: векторні представлення тексту

Ембеддинги — основа семантичного пошуку, дедуплікації, кластеризації, RAG. Якість критично впливає на downstream задачі.

Моделі. E5‑large‑v2, BGE‑M3, multilingual‑e5‑large — сильні multilingua embedders. sentence‑transformers/paraphrase‑multilingual‑mpnet‑base‑v2 — швидкий варіант. Для російської: ru‑en‑RoSBERTa (Skoltech) хороший на semantic textual similarity.

Як оцінити якість ембеддингів? MTEB benchmark — стандарт. Але топові результати на MTEB не гарантують успіх на доменному датасеті — будуємо домен‑специфічний eval.

Fine‑tuning ембеддингів. Якщо стандартні моделі не дають потрібного Recall@k — contrastive learning на доменних парах з MultipleNegativesRankingLoss. 500‑2000 пар, 1‑3 епохи — 5‑15% приріст Recall@k.

Розмірність та зберігання. E5‑large: 1024 dim, float32 — 4KB на вектор. При 10M документів — 40GB. INT8 quantization знижує до 10GB. FAISS IVF_PQ — ще компактніше, але з втратами. Входить у наші рекомендації по деплою.

Вилучення інформації

Структуроване вилучення — одна з частих задач. Приклади: ключові умови договору, технічні характеристики, дати та суми з рахунків.

1. Regex + rule-based. Для ІПН, ЄДРПОУ, сум, дат — надійніше нейромережі. Не потребує даних.
2. NER + постобробка. Для варіативних форматів.
3. LLM з structured output. GPT‑4 / Claude з JSON schema — для складних документів. Вартість: залежить від обсягу документів. Для 10k+ документів/день — рахуємо економіку.

Гарантуємо гібрид: regex/NER для типових полів + LLM для edge cases. Сертифікат довіри: 5 років на ринку, >30 проектів.

Етапи роботи

Прототип на існуючих даних — 1‑3 тижні. Production‑система з CI/CD — 1.5‑2.5 місяця. Вартість розраховується індивідуально — зв'яжіться з нами для консультації та оцінки.

Що входить у роботу

• Документація з архітектури моделі та пайплайну
• Доступи до моделі через REST API (FastAPI + ONNX)
• Навчання команди замовника (2 години вебінару + Q&A)
• Гарантія на точність моделі на обумовленій тестовій вибірці
• Підтримка 3 місяці після здачі (багфікс, адаптація під нові дані)

Наш досвід

Понад 5 років у NLP, 30+ проектів від класифікації до RAG‑систем. Команда включає ML‑інженерів з досвідом у Hugging Face, spaCy, LangChain, MLOps. Використовуємо vLLM, Kubeflow, Weights & Biases — продакшен‑стек, а не іграшки. Замовте консультацію — оцінимо проект за 2 дні.