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

Оглавление:

  1. Введение
  2. Бизнес-проблема
  3. Проблема машинного обучения
  4. Ограничения бизнеса
  5. Метрика производительности
  6. Набор данных и анализ столбцов
  7. EDA и предварительная обработка
  8. Разработка функций
  9. Модели машинного обучения
  10. Поведение лучшей модели
  11. Окончательный конвейер данных
  12. Производство
  13. Будущая работа
  14. Репозиторий Linkedin и Github
  15. Рекомендации

1. Что такое мошенничество в сфере здравоохранения?

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

Мошенничество со стороны поставщиков медицинских услуг (поставщик услуг — это тот, кто предоставляет услуги пациентам и подает заявки на возмещение расходов) — одна из самых больших проблем, с которыми сталкивается Medicare. По данным правительства, общие расходы на Medicare выросли в геометрической прогрессии из-за мошенничества с претензиями Medicare. Мошенничество в сфере здравоохранения — это организованное преступление, в котором участвуют равные поставщики, врачи, получатели помощи, действующие вместе, чтобы подать заявление о мошенничестве. Тщательный анализ данных Medicare выявил многих врачей, занимающихся мошенничеством. Они перенимают методы, в которых двусмысленный диагностический код используется для принятия самых дорогостоящих процедур и лекарств. Страховые компании являются наиболее уязвимыми учреждениями, пострадавшими из-за этой ненадлежащей практики.

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

  1. Выставление счетов за услуги, которые не были оказаны.
  2. Повторная подача заявки на одну и ту же услугу.
  3. Ложное представление об оказанной услуге.
  4. Взимание платы за более сложную или дорогую услугу, чем была предоставлена.
  5. Выставление счетов за покрываемую услугу, когда предоставленная услуга не была покрыта.

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

Это тематическое исследование направлено на «предсказание потенциально мошеннических поставщиков» на основе поданных ими претензий. Наряду с этим мы также обнаружим важные функции, полезные для обнаружения поведения потенциально мошеннических поставщиков. Далее мы изучим мошеннические схемы в претензиях провайдера, чтобы понять будущее поведение провайдеров.

3. Проблема с машинным обучением

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

4. Бизнес-ограничения

  1. Цена неправильной классификации очень высока. Как ложные срабатывания, так и ложные отрицания могут повлиять очень сильно.
  2. Интерпретируемость модели более важна, поскольку мы хотим знать, почему поставщик медицинских услуг является мошенническим или нет.
  3. У нас нет проблем с задержкой или временем, поскольку у нас есть 15–30 дней для обработки заявки.

5. Показатели производительности

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

Матрица путаницы для бинарной классификации, F1 Score и AUC Score — хорошо подходящие показатели производительности для этой бизнес-задачи.

1. Матрица путаницы

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

2. Точность, отзыв и оценка F1

а. Точность= Сколько из всех предсказанных положительных меток являются фактическими положительными метками. Он рассчитывается путем деления истинных срабатываний на сумму истинных срабатываний и ложных срабатываний.

b. Отзыв = Сколько из всех фактических положительных меток прогнозируется как положительное. Он рассчитывается путем деления истинно положительных результатов на сумму истинно положительных и ложноотрицательных результатов.

c. Оценка F1 = это среднее гармоническое точности и полноты. Его значение зависит от точности и отзыва.

3. Показатель AUC (площадь под кривой)

Полная форма AUC — это площадь под кривой. AUC кривой ROC обеспечивает совокупную меру производительности по всем возможным порогам классификации. Он также используется для различения двух кривых ROC.

AUC не зависит от прогнозируемых значений, а скорее учитывает порядок: если две модели дают одинаковый порядок прогнозируемых значений, то AUC будет одинаковым для обеих моделей.

AUC находится в диапазоне от 0 до 1. Предпочтительным значением AUC является значение > 0,5.

6. Набор данных и анализ столбцов

Набор данных, который я использовал в этом самостоятельном исследовании, загружен с Kaggle. Ссылка дана ниже

АНАЛИЗ ОБНАРУЖЕНИЯ МОШЕННИЧЕСТВА ПОСТАВЩИКОВ ЗДРАВООХРАНЕНИЯ | Kaggle

Введение в набор данных

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

  1. Набор данных получателя (обучение/тестирование)
  2. Набор стационарных данных (поезд/тест)
  3. Набор амбулаторных данных (обучение/тестирование)
  4. метка (поезд/тест)

1. Данные получателя (обучение/тестирование)

Эти данные содержат данные KYC получателя, такие как состояние здоровья, регион, к которому он принадлежит, и т. д.

  1. BeneID: BeneID – это уникальный идентификационный номер, присваиваемый пациенту.
  2. DOB:дата рождения пациента.
  3. DOD: дата смерти пациента.
  4. Пол, раса, штат, страна: пол, раса, штат и страна пациента.
  5. RenalDiseaseIndicator: это категориальный признак, который показывает, есть ли у пациента заболевание почек или нет.
  6. CronicCondi_*: это категориальный признак, указывающий, есть ли у пациента это хроническое заболевание или нет. Существуют различные типы хронических состояний, каждое из которых указано в отдельной колонке в наших данных о бенефициарах, некоторые из них: болезнь Альцгеймера, сердечная недостаточность, заболевание почек, рак, обструктивная легочная недостаточность, депрессия, диабет, ишемическая болезнь сердца, ревматоидный артрит, инсульт, остеопороз.
  7. IPAnnualReimbursementAmt: это общая сумма возмещения, требуемая за госпитализацию пациента ежегодно.
  8. IPAnnualDeductibleAmt: это общая сумма, ежегодно выплачиваемая пациентом за госпитализацию.
  9. OPAnnualReimbursementAmt: это общая сумма возмещения за OPD.
  10. OPAnnualDeductibleAmt: сумма, ежегодно выплачиваемая пациентом за OPD.

2. Стационарные данные (поезд/тест)

Эти данные дают представление об исках, поданных для тех пациентов, которые поступают в больницы. Он также предоставляет дополнительные сведения, такие как даты поступления и выписки, а также допускает коды диагнозов и т. д.

  1. BeneID.BeneID — это уникальный идентификационный номер, который присваивается пациенту.
  2. ClaimID: уникальный идентификационный номер, присваиваемый каждому заявлению, отправленному поставщиком.
  3. ClaimStartDt: дата подачи претензии поставщиком.
  4. ClaimEndDt: состоит из даты, когда претензия была завершена.
  5. Поставщик: состоит из уникального идентификационного номера поставщика.
  6. InscClaimAmtReimbursed: состоит из суммы возмещения по конкретному иску.
  7. AttendingPhysician. Он состоит из уникальных идентификационных номеров врачей, которые посещали пациентов.
  8. OperatingPhysician: состоит из уникальных идентификационных номеров врачей, оперировавших пациентов.
  9. Другой врач: он состоит из уникального идентификационного номера врача, отличного от лечащего врача и оперирующего врача.
  10. DeductibleAmtPaid: это общая сумма, выплаченная пациентом поставщикам.
  11. ClmAdmitDiagnosisCode: уникальный код заявки на заболевание, по поводу которого госпитализирован пациент.
  12. ClmDiagnosisCode_(1–10): это категориальный признак, указывающий конкретный код диагноза претензии для пациента. Всего существует десять различных типов clmDiagnosisCode, каждый из которых указан в отдельном столбце в наших стационарных данных.
  13. ClmProcedureCode_(1–6): это категориальный признак, указывающий конкретный код процедуры заявления для пациента, в основном код для каждой процедуры, выполненной для пациента, которая имеет право на заявление. Всего существует десять различных типов clmDiagnosisCode, каждый из которых указан в отдельном столбце в наших стационарных данных.
  14. Дата поступления: дата поступления пациента в больницу.
  15. Данные о выписке: дата выписки пациента из больницы.
  16. DiagnosisGroupCode: он состоит из уникального кода для диагностики, которая проводится для пациентов.

3. Амбулаторные данные (обучение/тестирование)

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

Все столбцы такие же, как данные о стационаре, за исключением Дата поступления, Дата выписки и Код группы диагностики.

4. Данные маркировки (поезд/тест)

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

Набор тестовых данных содержит только столбец идентификаторов поставщиков.

7. EDA и предварительная обработка

  1. Набор данных ярлыков

В помеченном наборе данных 5410 строк и 2 столбца.

Наблюдения

  1. Метки классов в наборе данных меток сильно несбалансированы: 9% потенциальных мошеннических меток и 90,647% не мошеннических меток.
  2. В столбце PotentialFraud (метка класса) отсутствуют пропущенные значения.

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

Замена PotentialFraud YES на 1 и No на 0.

2. Набор данных получателя

Проверка сведений о получателе.

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

  1. только данные столбца смерти имеют значения Nan
  2. мы должны изменить пол на 1 и 0 с 1 и 2. (для удобства интерпретации)
  3. В RenalDiseaseIndicator мы должны заменить Y на 1.
  4. мы должны определить, есть ли у получателя хроническое заболевание или нет, заменив 2 на 0 (отсутствие хронического заболевания). Отсюда мы можем добавить еще одну функцию под названием Total_chronic_condition, просто добавив их.

Наблюдения

  1. Максимум бенефициаров принадлежит гонке 1, за которой следует гонка 2.
  2. Бенефициар принадлежит к расе 5 очень редко.
  3. Пол_0 — 57,09%, а пол_1 — 42,02%.
  4. Пол сбалансирован в наборе данных о бенефициарах.

Наблюдения

  1. Максимальный бенефициар исходит из кода штата 5.
  2. Очень немногие бенефициары имеют код штата 2.

Наблюдения

  1. Диапазон годового Reimberusemt стационарных данных составляет от 0 до 150000.
  2. Большинство пациентов получили нулевую «IPAnnualReimbursementAmt» до 25000.
  3. Очень немногие получили возмещение от 25000 до 1500000
  4. Сумма годового Reimbersuemt очень высока.
  5. Он следует распределению Гаусса с некоторой асимметрией.
  6. Разница между 99-м процентилем и 100-м процентилем очень велика.
  7. Около 80% бенефициаров получили возмещение менее 5000.

Наблюдения

  1. Большинство бенефициаров заплатили очень меньшую сумму поставщику
  2. Максимальная сумма, выплачиваемая провайдеру, составляет 40000
  3. Максимальная сумма, выплачиваемая провайдерам, составляет 38272,0
  4. 75 % или менее оплаченная сумма менее 1068
  5. Мы видим, что процентиль 100 очень велик по сравнению с процентилем 99,9. это может быть выбросом.

Наблюдения

  1. Максимальная сумма возмещения 100000.
  2. Большинство бенефициаров получили возмещение менее 10000.
  3. Максимальная сумма возмещения 102960
  4. 75 % получателей получили 1500 или меньше
  5. Мы видим, что 100 процентиль намного больше, чем 99,9 процентиль. Это может быть выбросом.
  6. Он следует распределению Гаусса с некоторой асимметрией.

Наблюдения

  1. Большинство бенефициаров платили провайдеру суммы в диапазоне от 0 до 2000
  2. Максимальная сумма, выплачиваемая госпиталю, составляет 14000
  3. Он следует распределению Гаусса с некоторой асимметрией.
  4. Максимальная сумма, выплачиваемая получателем, составляет 13840
  5. 75 % или меньше уплаченной суммы 460
  6. Мы видим, что процентиль 100 очень велик по сравнению с процентилем 99,8. это может быть выбросом.

Наблюдения

  1. IPAnnualDeductibleAmt очень сильно коллинеарно IPAnnualReimbursementAmt с 0,97.
  2. OPAnnualReimbursementAmt коллинеарна OPAnnualDeductibleAmt с коэффициентом 0,66.

Мы можем удалить одну из функций IPAnnualDeductibleAmt или IPAnnualReimbursementAmt.

3. Амбулаторные данные

Наблюдения

  1. Максимальная сумма, заявленная для возмещения, составляет 102500.
  2. 75 % поля претензии на сумму 200.
  3. В наших данных могут быть некоторые выбросы.
  4. Большая часть суммы лежит в диапазоне от 0 до 5000.

Наблюдения

  1. Максимальный вычет Amtpaid составляет 897.
  2. 75% пациентов заплатили нулевую (0) франшизу.
  3. В DeductibleAmtPaid есть некоторые отклонения.

Наблюдения

  1. PHY330576 посетил максимальное количество амбулаторных пациентов.
  2. 1300 вокруг пациентов, которых не посещал врач.
  3. Более 400 000 больных, которых не осматривал ни один из оперирующих врачей.

Наблюдения

  1. Существует множество коллинеарных признаков, если амбулаторные данные
  2. InscClaimAmtReimbursed с ClmProcedureCode_4
  3. ClmProcedureCode_4 с ClmProcedureCode_2

мы могли бы удалить clmProcedureCode_4 в окончательных данных

4. Стационарные данные

Большинство признаков являются общими, как и в амбулаторных условиях.

Создание новых функций

Данные получателя

Dead_or_Alive: у нас есть почти все значения в DOD (дата смерти) NaN, поэтому мы можем добавить еще один столбец независимо от того, мертв он или нет.
если значение равно Nan, это означает, что он жив( 0) или дата означает, что он мертв(1).

Возраст: мы будем рассчитывать возраст на основе самой последней даты, представленной в наших данных.

Наблюдения

  1. максимум пациентов относятся к возрастной группе от 80 до 50 лет
  2. очень немногие пациенты относятся к возрастной группе 30 лет и младше.

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

Наблюдения

  1. Большинство пациентов имеют от 1 до 6 хронических заболеваний.
  2. Очень немногие из них имеют все 10 хронических заболеваний.

Admitted_or_not:добавляя новый столбец для того, госпитализирован ли пациент или нет для данных о стационаре, мы укажем его с 1.

Объединение всех четырех наборов данных

  1. Во-первых, мы объединяем данные стационарных и амбулаторных пациентов по общим столбцам, присутствующим в обоих фреймах данных.
  2. Во-вторых, мы объединяем объединенный набор данных на первом этапе с данными получателя по BeneId (идентификатор получателя).
  3. В-третьих, мы объединяем метки поездов с объединенными выше данными, установленными по идентификатору поставщика.
  4. Объединение стационарных и амбулаторных данных

Объединение стационарных данных с амбулаторными данными в общем столбце через внешнее соединение.

Создание новых объектов в объединенном наборе данных

AdmissinonDt: мы получим количество дней допуска, вычитая DiscargeDt из AdmissinonDt.

заполнение значений nan значением 1, поскольку пациент госпитализирован на минимальный день, равный 1.

Claim_time: мы будем вычислять Claim_time, вычитая Claim_start_date из Claim_end_date.

Amount_get: мы рассчитаем сумму, которую получит пациент.

2. Объединение объединенных данных о стационарных и амбулаторных пациентах с данными получателей помощи

Слияние вышеуказанных объединенных данных с данными получателя на BeneId через внутреннее соединение.

3. Объединение объединенных данных о стационарных амбулаторных пациентах и ​​получателях с данными ярлыков

Слияние объединенных выше данных с данными метки поставщиком через внутреннее соединение.

Создание некоторых новых функций в окончательном наборе данных.

  1. total_ip_op_amount_reimb: расчет общей суммы ежегодного возмещения расходов на стационарное и амбулаторное лечение.
  2. total_ip_op_amount_deduct: расчет общей годовой франшизы для стационарных и амбулаторных пациентов.

Обработка пропущенных значений

1. AttendingPhysician, OperatingPhysician, OtherPhysician, имеющие значения Nan, это связано с тем, что конкретный бенефициар или пациент не посещал врача, мы можем заполнить эти отсутствующие значения **0**

2. Дата поступления и выписки имеет значения Nan для амбулаторного пациента, поэтому мы можем заполнить эти значения 0

3. Код диагностики претензии и код процедуры претензии могут иметь значения Nan, которые стали конкретным кодом, который не может быть применен к пациенту, поэтому мы можем заполнить значения Nan 0

4. DOD (дата смерти) не применима к живым пациентам, поэтому мы можем заполнить эти значения 0

EDA для окончательного объединенного набора данных

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

Наблюдения

Гонка

  1. Почти все из рас 5 и 3 принадлежат PotentialFraud.
  2. Есть 50–50 шансов, что если провайдеры принадлежат к расе 1, относятся к мошенничеству или нет.

Возраст

Есть наложение, которое мы не можем различить по Возрасту Бенефициара.

Наблюдения

Claim_time по сравнению с допустимыми_днями

1. Существует перекрытие в поле Claim_time и Admitted_day, мы не можем ничего сделать из допущенных дней и дней заявления.

Возраст и допустимые_дни

  1. У провайдера мошенничества нет. допущенных_дней больше.
  2. Количество допустимых дней больше для возрастной группы от 25 до 45 лет. мы видим резкое увеличение.
  3. Возраст и число допустимых_дней могут хорошо сработать при обнаружении потенциального мошенничества.

Наблюдения

Claim_time и Total_chronic_cond

  1. Время требования больше для более хронического состояния.
  2. Более 5 хронических состояний требуют времени от 25 до 35 дней.

Total_chronic_condition_belong_to_potentialМошенничество

  1. В pdf total_chronic_condition есть перекрытия

Наблюдения

IPAnnualDeductibleAmt и IPAnnualReimbursementAmt

  1. Распределение IPAnnualReimbursementAmt перекрывается.
  2. Распределение IPAnnualDeductibleAmt также перекрывается.
  3. Есть несколько моментов, в которых вычитаемая сумма и возмещение являются высокими для мошенничества.
  4. Большинство баллов имеют низкую сумму франшизы и высокие суммы возмещения.

OPAnnualReimbursementAmt и OPAnnualDeductibleAmt

  1. OPAnnualReimbursementAmt и OPAnnualDeductibleAmt плотны в областях x=20000 и y=4000.
  2. Большинство точек перекрываются.
  3. Особенности выглядят коллинеарными

Наблюдения

Distribution_Of_Total_ip_op_amount_reimb

  1. В раздаче есть совпадения.
  2. Большая часть общего количества стационарных амбулаторных больных составляет от 0 до 5000.

Distribution_Of_total_ip_op_amount_deduct

  1. В распределении есть перекрытие.
  2. Максимальный общий вычет в сумме равен 0.

Наблюдения

  1. Допустимые дни коллинеарны выплаченной франшизе.
  2. InscClaimAmountReimbursed с получением суммы.
  3. Total_in_out_anual_reimbrused с IPanualAmtReimbrused.

Анализ коллинеарных признаков

Все эти функции показывают коллинеарность

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

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

Наш набор данных Train содержит в общей сложности 374001 строку, а набор данных проверки содержит в общей сложности 184210 строк, в каждом из которых по 64 столбца.

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

  1. Использование группы

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

мы получаем среднее значение поставщика для x_train и X_cv отдельно, чтобы избежать проблем с утечкой данных.

а. InscClaimAmtReimbursed

б. IPAnnualReimbursementAmt

в. OPГодовая сумма возмещения

В приведенном выше коде я создал новую функцию с именем Mean_InscClaimAmtReimbursed путем поиска поставщиков. Я сделал то же самое для IPAnnualReimbursementAmt и OPAnnualReimbursementAmt, чтобы получить Mean_IPAnnualReimbursementAmt и Mean_OPAnnualReimbursementAmt соответственно.

2. Подсчитайте функции.

Получение количества различных врачей, посещавших бенефициара (пациента), clmDiagnosisCode и ClmProcedurecode.

а. Количество посещенных врачей.

б. Количество ClmDiagnosisCode

в. Счетчик ClmProcedureCode.

Я создал новые функции подсчета в наших наборах данных для обучения и проверки.

3.Категориальные характеристики

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

Для этого мы получили все данные о мошенничестве из X_train. и получить от него 10 или 20 лучших кодов для каждой конкретной функции, и я делаю однократное кодирование для тех кодов, которые представлены в нашем поезде и данных проверки.

Мы сделали это для следующих функций:

а. ClmAdmitDiagnosisCode

б. ClmDiagnosisCode

в. Лечащий врач, оперирующий врач и другой врач

Я сделал то же самое, что и выше, для ClmDiagnosisCode, AttendingPhysician, OpertaingPhysician и OtherPhysician.

4. Различия

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

а. Diff_max_IPГодовая сумма возмещения

б. Diff_max_OPAnnualReimbursementAm

в. Diff_max_InscClaimAmtReimbursed

Обработка категориальных данных

Здесь я делаю однократное кодирование категориальных данных для следующих функций.

Штат, страна, раса, пол, NoOfMonths_PartCAov и NoOfMonths_PartBCov

Я сделал то же самое, что и выше, для состояния, расы, пола, NoOfMonths_PartCAov и NoOfMonths_PartBCov.

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

Удаление избыточных функций, таких как DOD, DOB и другие функции даты, а также удаление функций, которые я закодировал вручную, Provider Id, BeneId и других из данных обучения и проверки.

Форма окончательных X_train и X_cv после удаления избыточных функций будет (374001, 497), (184210, 497).

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

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

2. Окончательный набор данных без выбросов и коллинеарных признаков
Согласно EDA мы получили некоторые коллинеарные значения, и теперь мы их удаляем.
1. Допущенные дни совпадают с вычитаемой суммой.
2. InscClaimAmountReimbursed с Amount get.
3. Total_in_out_anual_reimbrused с IPanualAmtReimbrused.
4. IPAnnualDeductibleAmt очень коллинеарна IPAnnualReimbursementAmt с 0,97.

Удаление одной из коллинеарных функций.

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

Нормализация непрерывных данных

После создания предварительно обработанных данных мы нормализовали непрерывные данные, чтобы сделать их масштабно-инвариантными, нормализация помогает повысить точность модели. Мы нормализуем как набор данных-1 (с выбросами), так и набор данных-2 (без выбросов и коллинеарных функций).

9. Модели машинного обучения

мы создали два набора данных, набор данных-1 (с выбросами) и набор данных-2 (без выбросов и коллинеарных функций). Теперь мы будем обучать различные модели с настройкой гиперпараметров, чтобы получить модель с наилучшей производительностью. мы также будем использовать важные функции для обучения нашей лучшей модели.

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

Я обучил логистическую регрессию, наивный байесовский анализ, дерево решений, случайный лес и классификатор LightGBM для набора данных-1, набора данных-2 и 200 наиболее важных функций обоих наборов данных.

200 основных важных функций обоих наборов данных

Я использую модель случайного леса, чтобы получить важные функции. здесь слева у нас есть важные функции набора данных-2, а справа у нас есть важные функции набора данных-1.

Вот сравнение набора данных-1 и набора данных-2 с разными моделями и с важными функциями, обученными на лучшей модели.

Из приведенной выше таблицы мы можем заключить, что LightGBM, обученный на наборе данных-1, дает наилучшие результаты теста AUC и теста F1.

Показатели лучшей модели

Для прогноза наилучшее значение Threshold равно 0,382.

10. Поведение лучшей модели

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

Чтобы ответить на этот вопрос, мы проверяем распределение признаков, которые являются ложноположительными или ложноотрицательными, по данным с положительной меткой (только данные о мошенничестве) и данным с отрицательной меткой (только данные без мошенничества) соответственно, чтобы понять поведение модели.

Здесь мы отделяем ложноположительные и ложноотрицательные данные, положительные данные и отрицательные данные из набора данных.

Проверка распределения ложноотрицательных данных относительно отрицательных данных и ложноположительных данных относительно положительных данных для некоторых функций.

Наблюдение

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

11. Окончательный конвейер данных

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

Вывод:

Ниже я делюсь кодом для функции final_test, которая проверяет производительность модели на данных проверки, которая принимает два входа: один — данные проверки, а второй — соответствующие истинные метки.

Вывод:

12. Производство

Для производственной реализации модели я создал Flask API (интерфейс прикладного программирования), а для развертывания я использовал Heroku, который предоставляет платформу как услугу (PaaS), которая позволяет разработчикам создавать, запускать и управлять приложениями полностью в облаке.

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

Вот ссылка на развертывание видео.

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

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

14. Профиль LinkedIn и Github

  1. www.linkedin.com/in/abhishek-kundra-1817b61b2

2. https://github.com/Abhikundra/healthcare-provider-fraud-detection

15. Ссылки

  1. https://www.kaggle.com/rahuly93/medicare-provider-fraud-detection
  2. https://www.aaai.org/ocs/index.php/FLAIRS/FLAIRS18/paper/view/17617/16814
  3. https://cpb-us-w2.wpmucdn.com/sites.gatech.edu/dist/4/216/files/2015/09/p70-Statistical-Methods-for-Health-Care-Fraud-Detection.pdf
  4. [Особенность] Выявление мошенничества в сфере здравоохранения Medicare с помощью машинного обучения — UpLevel дает вам потрясающие кадры
  5. https:///www.appliedaicourse.com/