В последние годы система здравоохранения США стала одной из основных статей расходов. Согласно отчету GAO (Главного бухгалтерского управления) Конгрессу в 2004 году, ежегодные расходы на здравоохранение приближались к двум триллионам долларов, что составляло 15,3% ВВП (валового внутреннего продукта). Как размер системы, так и огромная сумма денег делают ее привлекательной мишенью для мошенничества.

Мошенничество в сфере здравоохранения является одной из основных проблем в системе здравоохранения США и приводит к огромным финансовым потерям, а также влияет на качество медицинских учреждений. Плательщики или страховые агентства, такие как Medicare, Medicaid и другие агентства, должны тратить больше денег, и чтобы понести финансовые потери, они должны принять решение об увеличении суммы страхового взноса. В конце концов, система здравоохранения становится все более и более дорогой.

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

Следовательно, эффективное обнаружение мошенничества с использованием сложных методов машинного обучения наряду с экспертными знаниями в области медицины очень важно для повышения качества и снижения стоимости медицинских услуг.

Оглавление

  1. Предпосылки
  2. Бизнес Проблема
  3. Машинное обучение постановке бизнес-задачи
  4. Бизнес-ограничения
  5. Источник данных
  6. "Показатели эффективности"
  7. Существующие подходы и улучшения по сравнению с ними
  8. Исследовательский анализ данных (EDA)
  9. Предварительная обработка данных
  10. Модели машинного обучения — настройка гиперпараметров и обучение модели
  11. Сравнение моделей
  12. Интерпретируемость модели
  13. Развертывание
  14. "Будущая работа"
  15. "Использованная литература"
  16. Гитхаб-репозиторий
  17. ЛинкедИн

Предпосылки

  1. Понимание статистических концепций/графиков.
  2. Концепции машинного обучения.

Бизнес-проблема

Мошенничество, расточительство и злоупотребление стали одной из самых серьезных проблем в системе здравоохранения Соединенных Штатов и могут быть вызваны различными субъектами здравоохранения (3 Ps), а именно пациентами (подписчик/получатель страховки), провайдеры медицинских услуг (больницы, врачи, лаборатории, аптеки и т. д.) и плательщики (поставщики страховых услуг, такие как Medicare, Medicaid и другие агентства). Мошенничество может быть вызвано как одним лицом, так и сговором нескольких лиц. В этом тематическом исследовании мы в первую очередь сосредоточимся на мошенничестве, совершенном поставщиками в рамках страховых требований, поданных в страховые агентства.

Многие системы здравоохранения полагаются на экспертов в предметной области, которые вручную рассматривают страховые претензии и выявляют потенциальные мошенничества. С течением времени генерируются данные от сотен тысяч до миллионов претензий. Проверка заявок вручную занимает очень много времени и является сложной задачей. Чтобы уменьшить такие усилия, можно использовать различные методы машинного обучения для автоматизации ручной обработки претензий и выявления потенциальных мошенничеств. Такая система, безусловно, поможет сократить затраты, объем ручного труда, время обработки и проверки, а также другие проблемы в системе. Это тематическое исследование направлено на решение проблемы выявления потенциальных случаев мошенничества в системе здравоохранения и на помощь в улучшении системы здравоохранения.

Машинное обучение Формулировка бизнес-задачи

Выявить потенциальные мошенничества, совершенные Поставщиками, в страховых претензиях, поданных в страховые агентства.

Проблема может быть спроецирована на задачу бинарной классификации для определения того, являются ли записи о претензиях, представленные поставщиками, мошенническими или законными. Учитывая данные, относящиеся к поставщикам и поданным ими претензиям, можно построить модель машинного обучения, чтобы определить, является ли запись претензии мошеннической или нет.

Ограничения бизнеса

  1. Нет требований к задержке. Поскольку текущий процесс ручной маркировки заявок как мошеннических или нет, занимает много времени, не будет строгой необходимости иметь систему с малой задержкой для обнаружения мошенничества. Тем не менее, время должно быть разумным в зависимости от потребностей бизнеса.
  2. Интерпретируемость. Интерпретируемость очень важна, поскольку модель машинного обучения должна обосновывать, почему она классифицирует заявку как мошенническую или нет. После выявления мошеннического требования, поданного ими, в отношении Провайдеров могут быть возбуждены судебные разбирательства. Следовательно, крайне важно, чтобы модель машинного обучения давала надлежащее обоснование в случае обнаружения мошенничества.
    Если законный поставщик будет обнаружен как мошенник и должен подвергнуться судебному разбирательству, он может запланировать ограничить свои возможности и сотрудничество с правительство, и доступность систем здравоохранения будет поставлена ​​под угрозу.
  3. Ошибки: процент ложноотрицательных результатов (FNR) должен быть как можно меньше. В некоторых системах здравоохранения, которые проводят некоторую ручную проверку после машинной классификации, допускается несколько более высокий показатель ложноположительных результатов (FPR). Тем не менее, FNR всегда должен быть минимальным, в противном случае фактические провайдеры мошенничества ускользнут и продолжат влиять на систему здравоохранения.
  4. Вероятности классов. Было бы лучше указать вероятности классов, чтобы пользователь мог знать, насколько вероятно конкретное мошенническое заявление.

Источник данных

Данные взяты с Kaggle:



АНАЛИЗ ОБНАРУЖЕНИЯ МОШЕННИЧЕСТВА МЕДИЦИНСКИМИ ПОСТАВЩИКАМИ
АНАЛИЗ ОБНАРУЖЕНИЯ МОШЕННИЧЕСТВА МЕДИЦИНСКИМИ ПОСТАВЩИКАМИwww.kaggle.com



Сведения о наборе данных

Набор данных представлен в виде файлов Excel, всего восемь файлов, по четыре для каждого поезда и тестовых данных. Это:

  1. Данные сопоставления (Train-1542865627584.csv и Test-1542969243754.csv): содержит сопоставление уникального идентификатора поставщика и метки класса, указывающей, является ли поставщик мошенническим или нет. Для тестовых данных дается только уникальный идентификатор поставщика, и необходимо найти метку класса.
  2. Данные получателя (Train_Beneficiarydata-1542865627584.csv и Test_Beneficiarydata-1542969243754.csv): содержит демографические данные, сведения о заболеваниях, страховых взносах и возмещении расходов получателей/пациентов.
  3. Стационарные данные (Train_Inpatientdata-1542865627584.csv и Test_Inpatientdata-1542969243754.csv): содержит подробные сведения о заявлениях, поданных для пациентов, которые были госпитализированы для лечения.
  4. Амбулаторные данные (Train_Outpatientdata-1542865627584.csv и Test_Outpatientdata-1542969243754.csv): содержит подробные сведения о заявлениях, поданных в отношении пациентов, которые посещали больницы, но не были госпитализированы.

Сведения о столбце

Каждый из столбцов, представленных на листах Excel, описан ниже:

  • Данные сопоставления
    Данные сопоставления присутствуют как для обучения, так и для тестирования.
    Данные обучения:
    1. Поставщик: уникальный идентификатор поставщика (больница, аптека, лаборатория и т. д.).
    2. Потенциальное мошенничество: ярлык класса, указывающий, является ли поставщик мошенником или нет.
    Тестовые данные. Тестовые данные содержат только уникальный идентификатор поставщика, а не метку класса, поскольку метку класса необходимо выяснить.
  • Данные получателя
    1. BeneID: уникальный идентификатор пациента/бенефициара, зарегистрированного в системе медицинского страхования, предоставляемой плательщиком (страховыми агентствами, такими как Medicare, Medicaid и другими агентствами).
    2. ГД. : Дата рождения бенефициара.
    3. DOD: Дата смерти бенефициара в случае, если бенефициар умер. В противном случае содержит значение NaN.
    4. Пол, раса, штат, страна: содержит числовой код для пола, расы, штата и страны получателя.
    5 RenalDiseaseIndicator: отметьте, чтобы указать, есть ли у бенефициара какие-либо проблемы, связанные с почечной недостаточностью.
    6. Столбцы хронического состояния: укажите, есть ли у бенефициара заболевание в течение более года и требует постоянного медицинского наблюдения или ограниченной активности в повседневной жизни, или и того, и другого. Есть столбцы, чтобы указать, есть ли у получателя хронические заболевания, связанные с болезнью Альцгеймера, сердечной недостаточностью, заболеванием почек, раком, обструктивной болезнью легких, депрессией, диабетом, ишемической болезнью сердца, остеопорозом, ревматоидным артритом и инсультом.
    7. IPAnnualReimbursementAmt: ежегодная сумма, возмещаемая за лечение бенефициара при поступлении в больницу.
    8. IPAnnualDeductibleAmt: ежегодная сумма страхового взноса, выплачиваемая Страховому агентству на лечение бенефициара, когда он был госпитализирован.
    9. OPAnnualReimbursementAmt: ежегодная сумма, возмещаемая за лечение бенефициара, когда он посетил больницу, но не госпитализирован.
    10. OPAnnualDeductibleAmt: сумма ежегодного страхового взноса, уплаченная Страховому агентству за лечение бенефициара, когда он посетил больницу, но не был госпитализирован.
  • Стационарные и амбулаторные данные:
    1. BeneID: уникальный идентификатор бенефициара.
    2. ClaimID: уникальный идентификатор страхового возмещения.
    3. ClaimStartDtи ClaimEndDt: даты подачи страхового возмещения, его урегулирования и закрытия.
    4. Поставщик: уникальный идентификатор поставщика.
    5. InscClaimAmtReimbursed: сумма, возмещаемая плательщиком (страховым агентством) за медицинские услуги, оказанные бенефициару.
    6. Столбцы, связанные с врачами: столбцы, показывающие врачей, которые посещали бенефициара/пациента, оперировали пациента, а также любых других врачей, если таковые имеются.
    7. Прием и Дата выписки (данные о стационаре): столбцы, показывающие даты госпитализации бенефициара и даты его выписки.
    8. ClmAdmitDiagnosisCode: код диагноза, указывающий первоначальный диагноз бенефициара при поступлении.
    9. Коды диагноза 1–10:
    ClmDiagnosisCode_1: код диагноза, идентифицирующий основной диагноз бенефициара.
    ClmDiagnosisCode_2–10: диагностический код во 2-й, 3-й и так далее до 10-й позиции, определяющий состояние(я), по поводу которого получатель помощи получает лечение.
    10. >Коды процедуры подачи заявления 1–6: коды, указывающие на основные или другие процедуры, выполненные в течение периода, охватываемого заявлением учреждения.
    11. Код группы диагнозов (данные стационара): код для классификации больничных случаев в соответствии с определенными группами, также называемыми DRG, которые, как ожидается, будут иметь одинаковое использование ресурсов больницы (стоимость).
    12. DeductibleAmtPaid: сумма, которую бенефициар должен заплатить в качестве часть претензии, а остальную сумму оплачивает страховая компания. Она равна общей сумме претензии за вычетом суммы возмещения.

Показатели эффективности

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

И. Потеря двоичного журнала: важная метрика, когда модель машинного обучения дает оценки вероятности. Он лежит в диапазоне от нуля до бесконечности. Чем ниже значение, тем лучше модель машинного обучения.
Задается уравнением:

II. Метрика производительности: матрица путаницы и другие связанные метрики:
Мы будем использовать матрицу путаницы и получать различные метрики из значений в матрице путаницы.
Матрица путаницы — это хорошая метрика для двоичной классификации, а также устойчивость к дисбалансу классов.
1. Матрица путаницы:
Матрица путаницы — это способ оценки эффективности модели классификации. Это сравнение между истинной реальностью (фактические значения) и прогнозируемыми значениями, выдаваемыми моделью для целевой переменной.

2. Матрица точности:
Матрица точности помогает узнать значения точности, лежащие на диагонали матрицы.

Точностьили прогнозируемое положительное значение (PPV) указывает на то, «сколько из всех прогнозируемых положительных результатов является фактическими положительными результатами».
уравнение:

Другая диагональ в матрице точности сообщает: «Сколько из всех предсказанных отрицательных результатов является действительными отрицательными значениями».
Задается уравнением:

3. Матрица отзыва:
Матрица отзыва помогает узнать значения отзыва (или чувствительности) и специфичности, которые лежат на диагональных элементах.

Отзыв/Чувствительностьили Показатель истинного положительного результата (TPR) указывает: «Сколько из всех фактических положительных результатов является прогнозируемым положительным».
Дано по уравнению:

Специфичность указывает на «Сколько из всех фактических отрицательных результатов является прогнозируемыми отрицательными значениями».
Задается уравнением:

4. Коэффициент ложноположительных результатов (FPR) и Коэффициент ложноотрицательных результатов (FNR):
Выпадение или Ложноположительные результаты Показатель (FPR) указывает «Сколько из всех фактических отрицательных результатов является прогнозируемыми положительными».
Рассчитывается по уравнению:

Коэффициент промаховили Коэффициент ложноотрицательных результатов (FNR) указывает: «Сколько из всех фактических положительных результатов является прогнозируемыми отрицательными».
Предоставляется уравнение:

III. Balanced Accuracy (BACC): фокусируется на высокой полноте (TPR и TNR).
Вычисляет сбалансированную точность и представляет собой среднее значение полноты, полученное для каждого класса.
Задается уравнением:

IV. Коэффициент корреляции Мэтью (MCC): учитывает все значения из матрицы путаницы и дает больше значения, когда прогнозы верны.
Задается уравнением:

IV. F1-Score: F1-Score — это мера точности теста.
F1-Score учитывает как Precision, так и Recall и представляет собой их среднее гармоническое.
Задается уравнением:

В. Площадь под кривой (AUC): AUC — это площадь под кривой рабочей характеристики приемника (ROC).

Существующие подходы и улучшения по сравнению с ними

Есть некоторые существующие решения и исследовательские работы по проблеме, которые приведены в ссылках. Существующие решения используют различные методы передискретизации и недостаточной выборки, но с ограниченным набором функций.

В этом решении мы увидим, что создали много новых функций, разработав функции для различных функций. Обеспечили отсутствие утечки данных при настройке гиперпараметров с k-кратной перекрестной проверкой с использованием Random Search CV, а также во время обучения и оценки модели. Кроме того, реализована интерпретируемость модели, чтобы объяснить, почему модель предсказывает конкретную запись претензии как мошенническую или нет.

Исследовательский анализ данных (EDA)

Исследовательский анализ данных (EDA) помогает анализировать данные с помощью простых инструментов из статистики, графиков, линейной алгебры и других.

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

  1. EDA набора данных поставщика:

Наблюдение:

  • Набор данных крайне несбалансирован: 90,6 % относятся к поставщикам, не занимающимся мошенничеством, и 9,4 % – к классу поставщиков, занимающихся мошенничеством.

2. EDA набора данных бенефициара:
2.1. EDA набора данных о бенефициарах — гендерная характеристика:

Наблюдение:

  • Гендерный признак почти сбалансирован.
  • 42,9% бенефициаров (пациентов) — мужчины, остальные 57,1% — женщины.

2.2. EDA набора данных бенефициара – функция гонки:

Наблюдение:

  • Есть четыре разных расы, закодированные как: «1», «2», «3» и «5».
  • Большинство бенефициаров (84,5%) принадлежат к расе «1», за которой следуют расы «2», «3» и «5».
  • Очень немногие бенефициары (2,1%) принадлежат к расе «5».

2.3. EDA набора данных бенефициара — функция RenalDiseaseIndicator:
Индикатор заболевания почек — это флаг, указывающий, есть ли у бенефициара какие-либо проблемы, связанные с почечной недостаточностью, или нет.

Наблюдение:

  • Поскольку эта функция является флагом, указывающим на любое заболевание почек, возможны два значения: 0/Нет и «Д»/Да.
  • Большинство бенефициаров (85,87%) не имеют заболеваний почек.

2.4. EDA набора данных бенефициара – функция состояния:

Наблюдение:

  • Всего 52 штата.
  • Состояние с максимальным числом бенефициаров (8,70%) кодируется как «5».
  • Штат с минимальным количеством бенефициаров (0,14%) кодируется как «2».

2.5. EDA набора данных о бенефициарах — характеристика страны:
Всего в наборе данных 314 стран. Построение распределения данных по 50 ведущим странам.

Наблюдение:

  • Страны с максимальным числом бенефициаров расположены в следующем порядке: 200, 10, 20 и так далее.
  • Страны, закодированные как «200», имеют 2,85% бенефициаров.

2.6. EDA набора данных бенефициара — функции NoOfMonths_PartACov и NoOfMonths_PartBCov:

Наблюдение:

  • 99,16% данных в функции «NoOfMonths_PartACov» имеют значение «12», а 0,72% данных имеют значение «0».
  • 98,81% данных в функции «NoOfMonths_PartBCov» имеют значение «12».
  • Все остальные значения пренебрежимо малы.
  • Поскольку почти все значения этой функции имеют значение 12, эта функция не окажет никакого влияния на классификацию. Следовательно, мы можем отказаться от этих функций.

2.7. EDA набора данных бенефициара — характеристики хронического заболевания:

Наблюдение:

  • Каждая из характеристик хронического состояния имеет два значения: «1» и «2».
  • Значение «2» будет заменено на «0», чтобы обозначить «0» как «Нет» и «1» как «Да» позже во время характеристики.
  • Данные разумно сбалансированы для всех функций, кроме «ChronicCond_Cancer» и «ChronicCond_stroke», где данные несбалансированы.

2.8. EDA набора данных бенефициара — функции годового возмещения и вычитаемой суммы как для стационарного, так и для амбулаторного лечения:

Наблюдение:

  • Для функции IPAnnualReimbursementAmt большая часть суммы находится в диапазоне от 0 до 5000.
  • Для функции IPAnnualDeductibleAmt большая часть суммы находится в диапазоне от 0 до 2000.
  • Для функции OPAnnualReimbursementAmt большая часть суммы находится в диапазоне от 0 до 5000.
  • Для функции OPAnnualDeductibleAmt большая часть суммы находится в диапазоне от 0 до 2000.
  • Остальные суммы, превышающие вышеуказанные диапазоны, являются выбросами. В этом тематическом исследовании эти большие суммы могут быть потенциальными случаями мошенничества. Следовательно, мы не будем удалять эти выбросы.

2.9. EDA набора данных бенефициаров — признак даты рождения:

Наблюдение:

  • Большинство больных родились в 1941 году, затем следуют годы: 1939, 1943, 1940 и так далее.

2.10. EDA набора данных бенефициара — функция даты смерти:

Наблюдение:

  • Все умершие пациенты умерли в «2009 году».
  • Большинство умерших пациентов скончались в декабре месяце.

3. EDA для набора данных для стационарных и амбулаторных пациентов
Набор данных для стационарных пациентов имеет в общей сложности 30 функций, а набор данных для амбулаторных пациентов — 27 функций.
Все 27 функций амбулаторного пациента также присутствуют. в наборе данных стационарного лечения.
Набор данных стационарного лечения имеет 3 дополнительные функции, а именно: «AdmissionDt», «DischargeDt» и «DiagnosisGroupCode».
Следовательно, мы объединим данные из набора данных стационарного и амбулаторного лечения вместе с общие столбцы и выполнить EDA для объединенных данных.

3.1. EDA набора данных о претензиях (стационарных и амбулаторных) — функции даты:
В наборе данных претензии есть четыре функции дат, а именно ClaimStartDt, ClaimEndDt, AdmissionDt и DischargeDt.

Мы получим следующие новые функции из этих функций даты для выполнения EDA:
1. Задержка урегулирования претензии: разница между датой окончания претензии и датой начала претензии.
2. Продолжительность лечения: разница между датой выписки и Дата поступления.

Наблюдение:

  • Распределение данных в функциях «ClaimSettlementDelay» и «TreatmentDuration» следует аналогичному шаблону. «Продолжительность лечения» присутствует только для стационарных данных, но не для амбулаторных данных.
  • Следовательно, мы можем оставить «ClaimSettlementDelay» и отказаться от функции «TreatmentDuration».
  • Кроме того, распределение данных для обоих классов (мошеннических и немошеннических) для каждой функции следует одной и той же тенденции.
  • В этой функции есть выбросы как для мошеннических, так и для немошеннических случаев, которые не следует удалять, поскольку они могут быть критическими факторами для определения того, является ли запись претензии мошеннической или нет.

3.2. Набор данных EDA of Claim (для стационарных и амбулаторных пациентов) — характеристики суммы:

Наблюдение:

  • Из PDF-файла видно, что распределение данных положительного и отрицательного классов имеет почти одинаковое распределение.
  • Из диаграммы мы видим, что существует много выбросов как для мошеннических, так и для немошеннических классов.
  • Однако мы не будем удалять выбросы, потому что этот признак является важным признаком претензии, а записи, соответствующие выбросам, могут быть классифицированы как потенциальный случай мошенничества, если этот признак объединяется с другими признаками для классификации.

Наблюдение:

  • Для функции «DeductibleAmtPaid» большинство значений сумм равны нулю.
  • Из-за слишком большого количества нулевых значений мы видим ненулевые значения как выбросы на блочной диаграмме.

3.3. Набор данных EDA of Claim (для стационарных и амбулаторных пациентов) — функция ClmAdmitDiagnosisCode:

Наблюдение:

  • Из 50 лучших категорий функции «ClmAdmitDiagnosisCode» мы видим, что все коды (категории) присутствуют как для положительных (мошенничество), так и для отрицательных (не мошенничество) случаев.
  • Из нижних 50 категорий функции ClmAdmitDiagnosisCode мы видим, что некоторые коды (категории) отсутствуют для обоих классов, но присутствуют для любого из них. Например, категория «V452» присутствует только один раз для дел о мошенничестве, а категория «37883» присутствует только один раз для дел, не связанных с мошенничеством.
  • Пять самых популярных диагностических кодов при приеме претензий: «V7612», «42731», «78605», «4019» и «25000».

3.4. EDA набора данных о претензиях (стационарных) — функция DiagnosisGroupCode:

Наблюдение:

  • Из 50 основных категорий функции «DiagnosisGroupCode» мы не можем извлечь много информации.
  • Из нижних 50 категорий функции «DiagnosisGroupCode» мы видим, что есть несколько кодов, которые встречаются только один раз (количество = 1). В функции «ClmAdmitDiagnosisCode» сравнительно много кодов, которые встречаются только один раз.
  • Мы не можем вывести много значимого понимания из этой функции.

3.5. Набор данных EDA для заявлений (стационарных и амбулаторных) — функции диагностических кодов заявлений:
здесь мы проведем EDA для всех десяти функций кодов диагностики заявлений.
i. ClmDiagnosisCode_1: диагностический код, идентифицирующий основной диагноз бенефициара.
ii. ClmDiagnosisCode_2–10: Код диагноза во 2-й, 3-й и так далее до 10-й позиции, определяющий состояние(я), по поводу которого бенефициар получает помощь.

Наблюдение:

  • Из всех диагностических кодов код «4019» имеет самый высокий процент претензий.
  • В «ClmDiagnosisCode_1» 2-й и 3-й наиболее часто встречающиеся коды — «4011» и «2724» соответственно.
  • Во всех функциях, кроме ClmDiagnosisCode_1, 2-й и 3-й наиболее часто встречающиеся коды — «25000» и «2724» соответственно.
  • Коды «4019», «2724» и «42731» встречаются во всех функциях.

3.6. EDA набора данных стационарного лечения — функции кодов процедуры подачи заявления:

Наблюдение:

  • Для «ClmProcedureCode_1» чаще всего встречается код «9904.0», за которым следуют «8154.0», «66.0», «3893.0», «3995» и т. д. Ни один из этих 5 кодов не встречается ни в одном из 10 основных кодов других 4 функций.
  • Код «4019.0» чаще всего встречается в трех функциях «ClmProcedureCode_2», «ClmProcedureCode_3» и «ClmProcedureCode_4».
  • Наиболее распространенными кодами во всех 5 функциях являются «2724.0», «5185.0» и «4139.0» с четырьмя вхождениями.
  • Функции «ClmProcedureCode_4» и «ClmProcedureCode_5» имеют очень незначительные (~ 0%) коды и могут быть удалены.

3.7. EDA набора данных о стационаре — функции врача:

Наблюдение:

  • На каждом из графиков «Лечащий врач», «Оперирующий врач» и «Другой врач» видно, что лучшие врачи (число 12+) участвуют только в делах о мошенничестве.
  • Врач «PHY330576» присутствовал, а также прооперировал большинство пациентов.
  • Около 2500+ пациентов посетил врач «PHY330576».
  • Врач «PHY330576» провел около 425 операций.
  • Врач «PHY412132» был еще одним врачом для большинства пациентов.

Предварительная обработка данных

И. Объединить наборы данных
Объединить данный набор данных как:

  • Столбцы стационарного и амбулаторного лечения содержат почти все одинаковые столбцы и, следовательно, могут быть объединены. Это даст единый набор данных, содержащий сведения как о стационарных, так и об амбулаторных пациентах, связанных с претензиями.
  • Результирующий набор данных можно объединить с набором данных получателя на основе идентификатора получателя, чтобы добавить информацию о получателе в набор данных.
  • Наконец, набор данных можно объединить с набором данных поставщика, чтобы сопоставить метку класса, чтобы решить, является ли поставщик мошенническим или нет.

II. Подготовка данных
Здесь мы проведем очистку, предварительную обработку и разработку функций данных.

  1. Очистка данных:
  • Преобразуйте функции, имеющие двоичные значения, указывающие флаги, такие как «Да»/«Нет», «Да»/«Нет» и 1/2 в 1/0.
  • Отбросьте столбцы со всеми нулевыми значениями.

2. Процент нулевых или пустых значений:

  • Проверьте процент пустых значений для каждого столбца в наборе данных.
  • Кроме того, постройте тепловую карту, чтобы увидеть процент отсутствующих значений в наборе данных.

Наблюдение:

  • Немногие диагностические коды и процедурные коды имеют высокий процент пустых значений в наборе данных.
  • Переменные, имеющие более 99,5% пустых ячеек:
    1. ClmProcedureCode_3
    2. ClmProcedureCode_4
    3. ClmProcedureCode_5
  • Эти столбцы можно удалить, так как почти все они содержат пустые ячейки и не будут сильно способствовать классификации.

3. Разработка функций:

3.1. Новые функции из Date Features:

  • Здесь мы создадим новые функции из функций даты:
    1. Задержка урегулирования претензии: разница между датой окончания претензии и датой начала претензии.
    2. Продолжительность лечения: разница между датой выписки и датой поступления.
    3. Возраст: по данным DOB.
    4. IsDead: по данным DOD.

3.2. Новые функции суммы возмещения и суммы франшизы:

  • Здесь мы создадим новые функции из функций:
    InscClaimAmtReimbursed, DeductibleAmtPaid, IPAnnualReimbursementAmt, IPAnnualDeductibleAmt, OPAnnualReimbursementAmt и OPAnnualDeductibleAmt.
  • TotalClaimAmount = InscAmtReimbursed + DeductibleAmtPaid.
  • IPTotalAmount = IPAnnualReimbursementAmt + IPAnnualDeductibleAmt.
  • OPTotalAmount = OPГодовая сумма возмещения + OPГодовая сумма вычетов.

3.3. Новые функции для обозначения стационарного и амбулаторного лечения:

  • Здесь мы создадим новую функцию под названием «IsInpatient», имеющую значение 1, если запись заявки предназначена для стационарных данных, и 0, если запись претензии предназначена для амбулаторных данных.
  • Поскольку функция «DiagnosisGroupCode» существует только для набора данных Inpatient, мы создадим значения для «IsInpatient» на основе того, является ли значение в функции «DiagnosisGroupCode».

3.4. Новые функции, связанные с функциями врача:

  • Мы получим новые функции из функций «Лечащий врач», «Оперирующий врач» и «Другой врач» следующим образом:
    1. UniquePhysCount: количество разных врачей, которые посещали/оперировали пациента и/или выполняли любую другую работу в записи заявки. .
    2. PhysRoleCount: общее количество лечащих, операционных и других врачей, которые работали с пациентом в записи заявки.
    3. IsSamePhysMultiRole1: флаг, указывающий, участвует ли один врач в нескольких ролях пациента в записи заявки.
    4. IsSamePhysMultiRole2: флаг, указывающий, что в записи заявки участвуют только два врача и один из них имеет несколько ролей.
  • Рассмотрим данные таблицы ниже, чтобы понять это лучше:

  • Будет создано 3 новых функции для 3 лучших врачей и подсчитано, сколько раз они появлялись в качестве лечащих, операционных или других врачей в записи заявки.
  • Если «PHY412132», «PHY337425» и «PHY330576» входят в тройку наиболее часто встречающихся врачей, рассмотрите приведенные ниже данные таблицы, чтобы понять новые функции:

3.5. Новые возможности диагностических кодов претензий и кодов процедур претензий:

  • Для всех функций, связанных с кодами диагностики претензий и кодами процедуры подачи заявок, мы создадим новые функции для первых кодов «k», аналогично тому, что мы сделали для трех лучших врачей выше.

3.6. Обновите функцию ClmAdmitDiagnosisCode и DiagnosisGroupCode:

  • Замените значение функций флагом, чтобы указать, существует ли значение или нет.

3.7. Новые функции для штата и страны:

  • Мы выполним следующие два вида кодирования для функций «Штат» и «Страна» после разделения данных на поезд, тест и резюме:
    1. Кодировка ответа: будет используется в моделях, подходящих для более низких измерений, таких как дерево решений, случайный лес, GBDT и т. д.
    2. Горячее кодирование: для модели, подходящей также для обработки больших измерений. Например, Наивный Байес, Логистическая регрессия и т.д.

4. График корреляции:

  • Мы построим график коэффициента ранговой корреляции Спирмена для окончательно подготовленного набора данных и посмотрим, можно ли удалить какие-либо функции на основе коэффициента корреляции.
  • Будем учитывать коэффициент корреляции порога 0,70.
  • Будет проверяться наличие пары признаков с коэффициентом корреляции более 0,70.
  • Из двух признаков в паре мы удалим признак с меньшим коэффициентом корреляции с меткой класса «PotentialFraud».

Наблюдение на графике корреляции:

  • Здесь мы видим, что несколько функций имеют высокий коэффициент корреляции Спирмена.
  • Коэффи- /> 4. ClmDiagnosisCode_3 и ClmDiagnosisCode_4: 0,74
    5. ClmDiagnosisCode_4 и ClmDiagnosisCode_5: 0,77
    6. ClmDiagnosisCode_5 и ClmDiagnosisCode_6: 0,84
    7. ClmDiagnosisCode_5 и ClmDia gnosisCode_7: 0,73
    8. ClmDiagnosisCode_6 и ClmDiagnosisCode_7: 0,87
    9. ClmDiagnosisCode_6 и ClmDiagnosisCode_8: 0,77
    10. ClmDiagnosisCode_7 и ClmDiagnosisCode_8: 0,89
    11. ClmDiagnosisCode_7 и ClmDiagnosisCode_9: 0,78
    12. ClmDiagnosisCode_8 и ClmDiagnosisCode_9: 0,87

Удаление функций:

  • Удаляет одну из функций среди этих пар, которая имеет меньший коэффициент корреляции с меткой класса «PotentialFraud».
  • Коэффициент корреляции объекта с меткой класса показан в скобках.
  • Удаление приведенной ниже функции среди пары функций на основе коэффициента корреляции с меткой класса:
    1. TreatmentDuration (0,11) и DiagnosisGroupCode (0,11): можно удалить любую функцию, так как обе имеют коэффициент корреляции 0,11 с меткой класса. Ярлык класса. Удалите функцию DiagnosisGroupCode здесь.
    2. TreatmentDuration (0,11) и ClmProcedureCode_1 (0,086): удалите функцию ClmProcedureCode_1.
    3. DiagnosisGroupCode (0,11) и ClmProcedureCode_1 (0,086): обе эти функции уже учтены для удаления.
    4. ClmDiagnosisCode_3 (0,034) и ClmDiagnosisCode_4 (0,045): удалить компонент ClmDiagnosisCode_3.
    5. ClmDiagnosisCode_4 (0,045) и ClmDiagnosisCode_5 (0,057): удалить компонент ClmDiagnosisCode_ 4 '.
    6. ClmDiagnosisCode_5 (0,057) и ClmDiagnosisCode_6 (0,064): удалить функцию "ClmDiagnosisCode_5".
    7. ClmDiagnosisCode_5 (0,057) и ClmDiagnosisCode_7 (0,069): "ClmDiagnosisCode_5" имеет меньший коэффициент и есть уже учтено в предыдущем пункте.
    8. ClmDiagnosisCode_6 (0,064) и ClmDiagnosisCode_7 (0,069): удалить функцию «ClmDiagnosisCode_6».
    9. ClmDiagnosisCode_6 (0,064) и ClmDiagnosisCode_8 (0,072): «ClmDiagnosisCode_6» имеет меньший коэффициент и уже учитывается в вышеуказанном пункте.
    10. ClmDiagnosisCode_7 (0,069) и ClmDiagnosisCode_8 (0,072): Удалить признак «ClmDiagnosisCode_7».
    11. ClmDiagnosisCode_7 (0,069) и ClmDiagnosisCode_9 (0,073) : 'ClmDiagnosisCode_7' имеет меньший коэффициент и уже учитывается в вышеуказанном пункте.
    12. ClmDiagnosisCode_8 (0,072) и ClmDiagnosisCode_9 (0,073): Удалить признак 'ClmDiagnosisCode_8'.

Код для всей предварительной обработки данных:

4. Обработка утечки данных

  • Какие бы функции ни были сгенерированы, проблем с утечкой данных нет.
  • Не производилось вменение данных на основе среднего значения, стандартного отклонения, медианы и т. д.
  • Стандартизация или нормализация данных также не проводилась до сих пор.
  • В отличие от методов вменения, таких как вменение среднего, которое учитывает все точки данных в наборе данных, новые функции, которые были сгенерированы, такие как врач, коды диагнозов, коды процедур и другие функции, связанные с кодом, получили значения с учетом соответствующей точки данных. и не все точки данных. Следовательно, это не приводит к какой-либо проблеме утечки данных.
  • Однако для создания новых функций для функций «Штат» и «Страна», таких как кодирование ответов и горячее кодирование, нам нужно рассматривать только набор обучающих данных, а не весь набор данных. В противном случае возникнет проблема с утечкой данных.
  • Нам нужно убедиться, что мы выполняем кодирование ответов, однократное кодирование или стандартизацию данных, рассматривая только обучающий набор данных, а не тестовый набор данных при обучении модели. В противном случае модель будет иметь доступ к данным, которых у нее не будет в прогнозах в реальном времени, и это приведет к тому, что модель будет работать лучше во время обучения и хуже в реальном времени.
  • Мы будем использовать конвейеры для устранения проблем с утечкой данных.

5. Кодирование категорийных признаков: кодирование ответа

  • Мы будем использовать кодировку ответа для функций «Штат» и «Страна».
  • Для каждой категориальной функции кодирование ответов создает «n» новых функций для задачи классификации «n» классов.
  • Поскольку эта проблема связана с бинарной классификацией для идентификации записи претензии как мошенничества или отсутствия мошенничества, будет создано в общей сложности 4 новых функции для функций «Штат» и «Страна» (по две для каждой функции).
  • Значение в новом признаке означает вероятностную вероятность признака с заданной меткой класса.
  • На изображении ниже объясняется концепция кодирования ответа:

  • Когда мы подбираем метод кодирования ответов к набору данных Train, он генерирует таблицу ответов и закодированные функции.
  • Тестовые данные преобразуются на основе таблицы ответов, и для тестового набора данных генерируются новые закодированные функции.
  • Метка ответа строится только на обучающем наборе данных. Для категории, которой нет в данных поезда, но которая присутствует в тестовых данных, мы будем кодировать их со значениями по умолчанию. Например, если в наших тестовых данных есть состояние «D», то мы кодируем его как [0,5, 0,05].

6. Категориальные признаки кодирования: однократное кодирование

  • Мы бы сделали однократное кодирование категориальных признаков, а именно «Штат» и «Страна».
  • Чтобы избежать проблем с утечкой данных, мы будем использовать конвейер sklearn.
  • Чтобы использовать Pipeline, нам нужно создать класс с методами fit() и transform(), наследующий класс BaseEstimator, TransformerMixin.

7. Кодирование числовых признаков: стандартизация столбцов

  • Мы стандартизируем следующие числовые характеристики, доступные в наборе данных:
    i. Гонка
    ii. Задержка урегулирования претензии
    iii. Продолжительность лечения
    iv. Возраст
    v. TotalClaimAmount
    vi. IPTotalAmount
    vii. OPTotalAmount
    viii. UniquePhysCount
    viii. PhysRoleCount
  • Опять же, для стандартизации функций нам нужно убедиться, что нет утечки данных.
  • Следовательно, мы создадим класс с методами fit() и transform(), наследующий класс BaseEstimator, TransformerMixin.

Модели машинного обучения — настройка гиперпараметров и обучение модели

  • Здесь мы выполним настройку гиперпараметров различных моделей машинного обучения, чтобы найти лучшие гиперпараметры.
  • С лучшими гиперпараметрами мы обучим модели с использованием различных методов выборки данных и проведем оценку.

Разделите набор данных для обучения и тестирования

  • Мы разделили бы данные в соотношении 80:20. 80 % данных будут использоваться для выполнения k-кратной перекрестной проверки гиперпараметров модели, а остальные 20 % данных (невидимых) будут использоваться для оценки модели.

Выборка — передискретизация и неполная выборка

  • Мы будем использовать различные методы выборки для выборки данных перед обучением моделей.
  • Мы бы сделали 4 вида выборки данных:
    1. Необработанные данные. Используйте необработанные данные без недовыборки или передискретизации.
    2. Сбалансированные веса классов: используйте сбалансированные веса классов.
    3. Случайная неполная выборка: случайная неполная выборка данных класса большинства, чтобы иметь такое же количество точек данных, что и в данных класса меньшинства.
    4. Передискретизация с использованием SMOTE: передискретизируйте данные класса меньшинства, чтобы иметь такое же количество точек данных, как и в данных класса большинства, используя SMOTE (Техника синтетической передискретизации меньшинства).
  • Мы будем использовать приведенные ниже модели машинного обучения для настройки и оценки гиперпараметров с каждым из 4 методов выборки:
    1. Логистическая регрессия.
    2. Дерево решений.
    3. Случайный лес.
    4. XGBoost.
    5. LightGBM.
  • Пример кода для настройки гиперпараметров, обучения модели с использованием лучших найденных гиперпараметров и выполнения оценки показан ниже:

  • Получив лучшие гиперпараметры с помощью k-кратной перекрестной проверки и случайного поиска, обучите модель, используя лучшие гиперпараметры, как показано ниже:
  • Оцените обученную модель по различным показателям производительности, которые обсуждались ранее. Результат выглядит следующим образом:

Сравнение моделей

  • Мы выполнили настройку гиперпараметров на различных моделях с использованием различных методов выборки, обучили модели и оценили их.
  • В таблице ниже показано сравнение между различными моделями, используемыми с различными методами выборки.
  • Ячейки, выделенные зеленым цветом, указывают наилучшее значение метрики по всем моделям.

One-Hot Encoding*: Однократное кодирование функций «Штат» и «Страна».
Кодирование ответа**: Кодирование ответа для функций «Штат» и «Страна».

  • Мы можем заметить, что:
    1. Дерево решений со сбалансированными весами классов получило наименьшую оценку «FNR» 0,24791.
    2. Случайный лес со сбалансированными весами классов получил минимальное значение «Обучить AUC» и минимальное значение «Обучить Log-loss».
    3. XGBoost с передискретизацией SMOTE получил наименьшее значение «Test Log-loss», «процент ошибочной классификации», «FPR» и максимальное значение «Test AUC», «F1-Score», «BACC». и оценка MCC.
  • Вывод. Поскольку модель XGBoost с передискретизацией SMOTE дает наилучшие результаты для большинства показателей производительности, мы выберем XGBoost с передискретизацией SMOTE в качестве окончательной модели.
  • Однако решение о выборе наилучшей модели в зависимости от того, какие показатели производительности следует учитывать, зависит от потребностей бизнеса.

Интерпретируемость модели

Интерпретируемость очень важна, поскольку модель должна обосновывать, почему она классифицирует запись претензии поставщика как мошенническую или нет.

Мы попытались обеспечить интерпретируемость модели, используя подходы:

  1. Глобальная структура данных: обеспечивает интерпретируемость модели с использованием важности функций, полученных моделью во всем обучающем наборе данных.
    На рисунке ниже показана интерпретируемость модели XGBoost с использованием важности функций 15 лучших функций:

Интерпретируемость с использованием важности признаков остается одинаковой для всех точек запроса.

2. Локальная структура точки запроса: обеспечивает интерпретируемость модели путем просмотра локальной структуры точек данных.
На рисунке ниже показана интерпретируемость модели для точки запроса с использованием LIME ( Техника Local Interpretable Model Agnostic):

Интерпретируемость с использованием LIME различна для каждой точки запроса, поскольку она учитывает локальную структуру точек запроса в ее окрестности.

Развертывание

Мы использовали Flask API для создания REST API, необходимых для производства модели.

Веб-приложение использует 4 листа Excel в требуемом формате, как указано в разделе «Источник данных», и дает прогноз того, являются ли претензии, представленные Поставщиками, мошенническими или нет.

Ниже приведена демонстрация с локального хоста (будет обновлена, чтобы показать демонстрацию из экземпляра AWS EC2 после решения нескольких проблем с установкой пакетов позже):

Будущая работа

Будущие масштабы этой проблемы могут быть следующими:

  • Реализация более сложных методов моделирования ансамбля, таких как наложение и каскадирование.
  • Разработайте глубокую модель многослойного персептрона (MLP) (модель глубокого обучения).
  • Объясните интерпретируемость модели, используя более продвинутые методы, такие как SHAP (аддитивные объяснения Шэпли).

Рекомендации

  1. Обнаружение мошенничества в Medicare с использованием моделей машинного обучения.
  2. Выявление мошенничества с Medicare с использованием методов ML с исключенными ярлыками поставщиков.
  3. Сравнительное исследование использования различных моделей обнаружения мошенничества на основе машинного обучения и глубокого обучения для схем универсального медицинского страхования.
  4. Выявление мошенничества с кредитными картами с использованием методов машинного обучения: сравнительный анализ.
  5. Выявление мошенничества с поставщиками медицинских услуг — Kaggle
  6. Прикладные корни.

Репозиторий GitHub



GitHub — pulkitratnaganjeer/HealthcareFraudDetection
Система здравоохранения США в последние годы стала одной из основных статей расходов, на которую приходится около 15% ВВП. Оба…github.com



LinkedIn



Пулкит Ганжир — главный инженер-программист — emids | LinkedIn
Опытный старший инженер-программист с подтвержденным опытом работы в сфере информационных технологий и услуг…www.linkedin.com