EXL прискорив обробку медичних страхових справ на AWS

Другий кейс: не страхові справи, а картки пацієнтів

Той самий рушій EXL застосували не лише в андерайтингу, а й у клінічному кейс-менеджменті великого страховика здоров'я. Медсестри та care coordinators теж витрачали понад 100 хвилин на справу — але не на перевірку документів для виплати, а на ручний пошук і звірку даних пацієнта, розкиданих між системами: електронні медичні картки, системи care management (EPIC, CarePort, Predictal), claims-системи та скановані медичні документи.

Компанія розгорнула єдиний конвеєр: API-оркестрація через ці системи, агенти вилучення, що обробляють одразу JSON, FHIR-пакети й скановані PDF, а модель класифікує медикаменти, історію хвороби, діагнози, процедури, лабораторні аналізи й нотатки лікаря. Дані звіряються з галузевими медичними кодами, а фінальний клінічний висновок формується з людською перевіркою. Результат — менше ручної роботи, швидше звернення до пацієнтів і вища пропускна здатність команди без розширення штату.

Сім кроків: що відбувається з документом усередині

Пайплайн EXL веде кожен пакет документів через послідовність етапів:

• Розбиття та класифікація: вхідний файл (навіть лист із кількома вкладеннями) розбивається на окремі документи й класифікується за змістом, а не за шаблоном чи розташуванням тексту.
• Вилучення даних з оцінкою впевненості: кожне вилучене поле отримує бал від 0 до 100; усе, що нижче порогу, автоматично йде на перевірку людині.
• Збагачення й звірка: коди ICD, CPT та HCPCS звіряються з довідниками, дати й терміни нормалізуються.
• Стисле резюме: користувач сам обирає коротке, середнє чи розгорнуте зведення документа.
• Запити природною мовою: можна ставити готові, пакетні або довільні питання про справу й отримати відповідь із посиланням на джерело.
• Поглиблене міркування з простежуваністю: кожен висновок веде назад до конкретного фрагмента документа.
• Структурований вивід: PDF-звіт, хронологічна карта діагнозів, або експорт у JSON/XML/CSV — залежно від того, яка система приймає результат далі.

Чому не обійшлися звичайним промптингом

У джерелі окремо пояснено логіку відмови від GPT-4 чи Claude напряму. Річ не лише в термінології ICD і CPT — загальним моделям бракує стійкості на трьох рівнях одразу: типах тегування медичних записів, форматах доменного резюме (окремо економічні й неекономічні збитки) та генерації рекомендацій для перемовин. Це саме ті задачі, де сам промпт без донавчання дає розкид результатів від справи до справи — прийнятний для одиничного запиту, але не для потоку в сотні сторінок щодня.

Приблизно 25–30% документів у таких справах містять рукописний текст — від заповнених від руки бланків до вільних нотаток лікаря. Кожен тип рукопису вимагає окремої обробки, і це ще один пласт складності, який не покривається універсальною моделлю без спеціального тренування.

Що перевірити, перш ніж довіритись висновку моделі

Сама архітектура закладає кілька запобіжників, і їх варто знати як критерії довіри до результату, а не приймати автоматично:

• Чи потрапило поле нижче порогу впевненості — якщо так, воно мало пройти перевірку людиною, а не піти в звіт напряму.
• Чи є посилання на першоджерело для кожного висновку чи відповіді — без цього узгодити висновок із оригіналом неможливо.
• Чи пройшов згенерований текст перевірку на відповідність вихідному документу (grounding), перш ніж потрапити до рецензента.
• Чи використано процедуру деідентифікації персональних медичних даних відповідно до HIPAA до етапу тренування чи обробки.

Дати запуску рішення й вартості в матеріалі немає.