Інтелектуальна обробка документів за допомогою AWS AI та сервісів Analytics у страховій галузі: Частина 2

In Частина 1 У цій серії ми обговорювали інтелектуальну обробку документів (IDP) і те, як IDP може прискорити обробку претензій у страховій галузі. Ми обговорили, як ми можемо використовувати служби AWS AI для точної категоризації документів претензій разом із супровідними документами. Ми також обговорили, як отримати різні типи документів у пакеті страхових вимог, наприклад форми, таблиці або спеціальні документи, такі як рахунки-фактури, квитанції або документи, що посвідчують особу. Ми розглянули проблеми, пов’язані зі старими процесами документообігу, які займають багато часу, спричиняють помилки, є дорогими та важкими для обробки в масштабі, а також те, як ви можете використовувати служби штучного інтелекту AWS, щоб допомогти реалізувати конвеєр IDP.

У цій публікації ми ознайомимо вас із розширеними функціями IDP для вилучення, запитів і збагачення документів. Ми також розглядаємо, як далі використовувати отриману структуровану інформацію з даних претензій, щоб отримати статистику за допомогою служб AWS Analytics і візуалізації. Ми підкреслюємо, як витягнуті структуровані дані з IDP можуть допомогти проти шахрайських претензій за допомогою служб AWS Analytics.

Огляд рішення

На наступній діаграмі показано етапи, якщо IDP використовує служби AWS AI. У Частині 1 ми обговорили перші три етапи робочого процесу IDP. У цій публікації ми детально розглянемо етап вилучення та інші етапи, які включають інтеграцію IDP зі службами AWS Analytics.

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

На етапах, які ми обговорюємо в цій публікації, використовуються такі ключові служби:

• Amazon Comprehend Medical – це служба обробки природної мови (NLP), яка відповідає вимогам HIPAA, яка використовує моделі машинного навчання (ML), які попередньо навчені розуміти та витягувати дані про стан здоров’я з медичних текстів, як-от рецепти, процедури чи діагнози.
• Клей AWS є частиною стеку служб AWS Analytics і є безсерверною службою інтеграції даних, яка спрощує пошук, підготовку та поєднання даних для аналітики, машинного навчання та розробки додатків.
• Амазонська червона зміна це ще одна служба в стеку Analytics. Amazon Redshift — це повністю керована служба сховища даних у петабайтному масштабі в хмарі.

Передумови

Перш ніж почати, зверніться до Частина 1 для високорівневого огляду сценарію використання страхування з ВПО та детальної інформації про етапи збору даних і класифікації.

Для отримання додаткової інформації щодо зразків коду зверніться до нашого Репо GitHub.

Фаза екстракції

У Частині 1 ми побачили, як використовувати API Amazon Texttract для отримання інформації, наприклад форм і таблиць, із документів, а також як аналізувати рахунки-фактури та документи, що посвідчують особу. У цій публікації ми вдосконалюємо фазу вилучення за допомогою Amazon Comprehend, щоб видобувати стандартні та користувацькі об’єкти, специфічні для спеціальних випадків використання.

Страхові перевізники часто стикаються з щільним текстом у заявках про страхові претензії, як-от підсумковий лист про виписку пацієнта (див. наступне приклад зображення). Може бути важко автоматично витягти інформацію з таких типів документів, де немає певної структури. Щоб вирішити цю проблему, ми можемо використати наведені нижче методи для вилучення ключової бізнес-інформації з документа:

Видобувайте сутності за замовчуванням за допомогою Amazon Comprehend DetectEntities API

Ми запускаємо наступний код у зразку документа про медичну транскрипцію:

comprehend = boto3.client('comprehend') 

response = comprehend.detect_entities( Text=text, LanguageCode='en')

#print enitities from the response JSON

for entity in response['Entities']:
    print(f'{entity["Type"]} : {entity["Text"]}')

На наступному знімку екрана показано набір сутностей, визначених у вхідному тексті. Вихідні дані було скорочено для цілей цієї публікації. Зверніться до GitHub репо для детального списку суб'єктів.

Витягуйте користувальницькі об'єкти за допомогою спеціального розпізнавання об'єктів Amazon Comprehend

Відповідь від DetectEntities API містить сутності за замовчуванням. Однак нам цікаво знати конкретні значення сутності, наприклад ім’я пацієнта (позначене сутністю за замовчуванням PERSON) або ідентифікатор пацієнта (позначений сутністю за замовчуванням OTHER). Щоб розпізнавати ці спеціальні об’єкти, ми навчаємо спеціальну модель розпізнавання об’єктів Amazon Comprehend. Ми рекомендуємо виконати вичерпні кроки щодо навчання та розгортання спеціальної моделі розпізнавання сутностей у Репо GitHub.

Після розгортання спеціальної моделі ми можемо використовувати допоміжну функцію get_entities() для отримання настроюваних сутностей, наприклад PATIENT_NAME та PATIENT_D із відповіді API:

def get_entities(text):
try:
    #detect entities
    entities_custom = comprehend.detect_entities(LanguageCode="en",
                      Text=text, EndpointArn=ER_ENDPOINT_ARN) 
    df_custom = pd.DataFrame(entities_custom["Entities"], columns = ['Text',  
                'Type', 'Score'])
    df_custom = df_custom.drop_duplicates(subset=['Text']).reset_index()
    return df_custom
except Exception as e:
    print(e)

# call the get_entities() function 
response = get_entities(text) 
#print the response from the get_entities() function
print(response)

Наступний знімок екрана показує наші результати.

Фаза збагачення

На етапі збагачення документів ми виконуємо функції збагачення документів, пов’язаних із охороною здоров’я, щоб отримати цінну інформацію. Ми розглядаємо наступні види збагачення:

• Витягніть доменно-залежну мову – Ми використовуємо Amazon Comprehend Medical для отримання специфічних медичних онтологій, таких як ICD-10-CM, RxNorm і SNOMED CT
• Видалення конфіденційної інформації – Ми використовуємо Amazon Comprehend для редагування особистої інформації (PII), а Amazon Comprehend Medical – для редагування захищеної медичної інформації (PHI).

Отримайте медичну інформацію з неструктурованого медичного тексту

Такі документи, як замітки медичних працівників і звіти про клінічні випробування, містять щільний медичний текст. Перевізникам страхових відшкодувань потрібно визначити зв’язки між витягнутою інформацією про здоров’я з цього щільного тексту та зв’язати їх із медичними онтологіями, такими як коди ICD-10-CM, RxNorm і SNOMED CT. Це дуже важливо для автоматизації робочих процесів реєстрації, перевірки та затвердження претензій для страхових компаній, щоб прискорити та спростити обробку претензій. Давайте розглянемо, як ми можемо використовувати Amazon Comprehend Medical InferICD10CM API для виявлення можливих захворювань як сутностей і зв’язування їх із їхніми кодами:

cm_json_data = comprehend_med.infer_icd10_cm(Text=text)

print("nMedical codingn========")

for entity in cm_json_data["Entities"]:
      for icd in entity["ICD10CMConcepts"]:
           description = icd['Description']
           code = icd["Code"]
           print(f'{description}: {code}')

Для вхідного тексту, який ми можемо передати з Amazon Texttract DetectDocumentText API, InferICD10CM API повертає наступний вихід (вихідні дані скорочено для стислості).

Так само ми можемо використовувати Amazon Comprehend Medical InferRxNorm API для ідентифікації ліків і InferSNOMEDCT API для виявлення медичних осіб у документах, пов’язаних із медичним страхуванням.

Виконайте редагування PII та PHI

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

Розглянемо приклад виписки пацієнта. Ми використовуємо Amazon Comprehend DetectPiiEntities API для виявлення ідентифікаційних сутностей у документі та захисту конфіденційності пацієнта шляхом редагування цих сутностей:

resp = call_textract(input_document = f's3://{data_bucket}/idp/textract/dr-note-sample.png')
text = get_string(textract_json=resp, output_type=[Textract_Pretty_Print.LINES])

# call Amazon Comprehend Detect PII Entities API
entity_resp = comprehend.detect_pii_entities(Text=text, LanguageCode="en") 

pii = []
for entity in entity_resp['Entities']:
      pii_entity={}
      pii_entity['Type'] = entity['Type']
      pii_entity['Text'] = text[entity['BeginOffset']:entity['EndOffset']]
      pii.append(pii_entity)
print(pii)

Ми отримуємо такі ідентифікаційні сутності у відповіді від detect_pii_entities() API:

Потім ми можемо відредагувати ідентифікаційні сутності, виявлені в документах, використовуючи геометрію обмежувальної рамки сутностей із документа. Для цього ми використовуємо допоміжний інструмент під назвою amazon-textract-overlayer. Для отримання додаткової інформації див Текстовий накладений шар. На наступних знімках екрана порівнюється документ до та після редагування.

Подібно до Amazon Comprehend DetectPiiEntities API, ми також можемо використовувати DetectPHI API для виявлення даних PHI у досліджуваному клінічному тексті. Для отримання додаткової інформації див Виявлення PHI.

Етап перевірки та перевірки

На етапі перевірки та перевірки документів тепер ми можемо перевірити, чи відповідає пакет претензій вимогам компанії, оскільки ми маємо всю інформацію, зібрану з документів у пакеті на попередніх етапах. Ми можемо зробити це, залучивши людину до циклу, яка може переглянути та підтвердити всі поля, або просто запустити процес автоматичного схвалення для низьких претензій перед надсиланням пакета до подальших програм. Ми можемо використовувати Розширений ШІ в Амазонці (Amazon A2I), щоб автоматизувати процес розгляду людьми для обробки страхових вимог.

Тепер, коли у нас є всі необхідні дані, витягнуті та нормалізовані з обробки претензій за допомогою служб AI для IDP, ми можемо розширити рішення для інтеграції з такими службами AWS Analytics, як AWS Glue і Amazon Redshift, щоб вирішити додаткові випадки використання та забезпечити подальшу аналітику та візуалізацію.

Виявляйте шахрайські страхові претензії

У цій публікації ми реалізуємо безсерверну архітектуру, де витягнуті й оброблені дані зберігаються в озері даних і використовуються для виявлення шахрайських страхових претензій за допомогою ML. Ми використовуємо Служба простого зберігання Amazon (Amazon S3), щоб зберігати оброблені дані. Тоді ми можемо використовувати Клей AWS or Amazon EMR щоб очистити дані та додати додаткові поля, щоб зробити їх придатними для звітності та ML. Після цього використовуємо Amazon Redshift ML створити модель ML для виявлення шахрайства. Нарешті, ми створюємо звіти за допомогою Amazon QuickSight щоб отримати уявлення про дані.

Налаштуйте зовнішню схему Amazon Redshift

Для цілей цього прикладу ми створили a зразок набору даних емулює результат процесу ETL (вилучення, перетворення та завантаження) і використовує AWS Glue Data Catalog як каталог метаданих. Спочатку ми створюємо базу даних з назвою idp_demo у каталозі даних і зовнішньої схеми в Amazon Redshift викликається idp_insurance_demo (див. наступний код). Ми використовуємо Управління ідентифікацією та доступом AWS (IAM) для надання дозволів кластеру Amazon Redshift на доступ до Amazon S3 і Amazon SageMaker. Щоб отримати додаткові відомості про те, як налаштувати цю роль IAM із найменшими привілеями, див Кластеризуйте та налаштуйте налаштування для адміністрування Amazon Redshift ML.

CREATE EXTERNAL SCHEMA idp_insurance_demo
FROM DATA CATALOG
DATABASE 'idp_demo' 
IAM_ROLE '<<>>'
CREATE EXTERNAL DATABASE IF NOT EXISTS;

Створіть зовнішню таблицю Amazon Redshift

Наступним кроком є ​​створення зовнішньої таблиці в Amazon Redshift із посиланням на розташування S3, де знаходиться файл. У цьому випадку наш файл є текстовим файлом, розділеним комами. Ми також хочемо пропустити рядок заголовка з файлу, який можна налаштувати в розділі властивостей таблиці. Перегляньте наступний код:

create external table idp_insurance_demo.claims(id INTEGER,
date_of_service date,
patients_address_city VARCHAR,
patients_address_state VARCHAR,
patients_address_zip VARCHAR,
patient_status VARCHAR,
insured_address_state VARCHAR,
insured_address_zip VARCHAR,
insured_date_of_birth date,
insurance_plan_name VARCHAR,
total_charges DECIMAL(14,4),
fraud VARCHAR,
duplicate varchar,
invalid_claim VARCHAR
)
row format delimited
fields terminated by ','
stored as textfile
location '<<>>'
table properties ( 'skip.header.line.count'='1');

Створіть навчальні та тестові набори даних

Після створення зовнішньої таблиці ми готуємо наш набір даних для ML, розділяючи його на набір для навчання та набір для тестування. Ми створюємо нову зовнішню таблицю під назвою claim_train, який складається з усіх записів з ID <= 85000 з таблиці вимог. Це навчальний набір, на якому ми навчаємо нашу модель ML.

CREATE EXTERNAL TABLE
idp_insurance_demo.claims_train
row format delimited
fields terminated by ','
stored as textfile
location '<<>>/train'
table properties ( 'skip.header.line.count'='1')
AS select * from idp_insurance_demo.claims where id <= 850000

Ми створюємо ще одну зовнішню таблицю під назвою claim_test який складається з усіх записів з ID >85000, щоб бути тестовим набором, на якому ми тестуємо модель ML:

CREATE EXTERNAL TABLE
idp_insurance_demo.claims_test
row format delimited
fields terminated by ','
stored as textfile
location '<<>>/test'
table properties ( 'skip.header.line.count'='1')
AS select * from idp_insurance_demo.claims where id > 850000

Створіть модель ML за допомогою Amazon Redshift ML

Тепер ми створюємо модель за допомогою СТВОРИТИ МОДЕЛЬ команда (див. наступний код). Вибираємо відповідні стовпці з claims_train таблицю, яка може визначити шахрайську транзакцію. Метою цієї моделі є прогнозування значення fraud колонка; отже, fraud додається як ціль передбачення. Після того, як модель навчена, вона створює функцію під назвою insurance_fraud_model. Ця функція використовується для висновку під час виконання операторів SQL для прогнозування значення fraud колонка для нових записів.

CREATE MODEL idp_insurance_demo.insurance_fraud_model
FROM (SELECT 
total_charges ,
fraud ,
duplicate,
invalid_claim
FROM idp_insurance_demo.claims_train
)
TARGET fraud
FUNCTION insurance_fraud_model
IAM_ROLE '<<>>'
SETTINGS (
S3_BUCKET '<<>>'
);

Оцініть показники моделі ML

Після створення моделі ми можемо запускати запити, щоб перевірити точність моделі. Ми використовуємо insurance_fraud_model функція для прогнозування значення fraud колонка для нових записів. Виконайте наступний запит на claims_test таблиця для створення матриці плутанини:

SELECT 
fraud,
idp_insurance_demo.insurance_fraud_model (total_charges ,duplicate,invalid_claim ) as fraud_calculcated,
count(1)
FROM idp_insurance_demo.claims_test
GROUP BY fraud , fraud_calculcated;

Виявляйте шахрайство за допомогою моделі ML

Після того як ми створимо нову модель, коли нові дані претензій буде вставлено в сховище даних або озеро даних, ми можемо використовувати insurance_fraud_model функція розрахунку шахрайських транзакцій. Ми робимо це, спочатку завантажуючи нові дані в тимчасову таблицю. Тоді ми використовуємо insurance_fraud_model функція для обчислення fraud для кожної нової транзакції та вставте дані разом із прапором у підсумкову таблицю, яка в даному випадку є claims таблиці.

Візуалізуйте дані претензій

Коли дані доступні в Amazon Redshift, ми можемо створювати візуалізації за допомогою QuickSight. Потім ми можемо надати доступ до інформаційних панелей QuickSight бізнес-користувачам і аналітикам. Щоб створити інформаційну панель QuickSight, спочатку потрібно створити набір даних Amazon Redshift у QuickSight. Інструкції див Створення набору даних з бази даних.

Після створення набору даних ви можете створити новий аналіз у QuickSight за допомогою набору даних. Нижче наведено кілька зразків звітів, які ми створили:

• Загальна кількість позовів за державами, згрупованих за fraud поле – Ця діаграма показує нам частку шахрайських транзакцій порівняно із загальною кількістю транзакцій у певному штаті.
• Загальна вартість претензій у доларах США, згрупована за fraud поле – Ця діаграма показує нам частку суми шахрайських транзакцій у доларах порівняно із загальною сумою транзакцій у доларах у певному штаті.
• Загальна кількість операцій на одну страхову компанію, згрупованих за fraud поле – Ця діаграма показує нам, скільки претензій було подано кожною страховою компанією та скільки з них є шахрайськими.

• Загальна сума шахрайських транзакцій за штатами, відображена на карті США – На цій діаграмі показано лише шахрайські транзакції та загальні витрати за ці транзакції за штатом на карті. Темніший відтінок синього вказує на вищі загальні витрати. Ми можемо додатково проаналізувати це за містами в цьому штаті та поштовими індексами з містом, щоб краще зрозуміти тенденції.

Прибирати

Щоб запобігти стягненню плати в майбутньому з вашого облікового запису AWS, видаліть ресурси, які ви надали під час налаштування, дотримуючись інструкцій у Розділ очищення в нашому репо.

Висновок

У цій серії з двох частин ми побачили, як побудувати наскрізний конвеєр IDP з невеликим досвідом або без нього. Ми дослідили сценарій обробки претензій у страховій галузі та те, як IDP може допомогти автоматизувати цей варіант використання за допомогою таких служб, як Amazon Texttract, Amazon Comprehend, Amazon Comprehend Medical і Amazon A2I. У частині 1 ми продемонстрували, як використовувати сервіси AWS AI для вилучення документів. У частині 2 ми розширили фазу вилучення та збагатили дані. Нарешті, ми розширили структуровані дані, отримані з IDP, для подальшої аналітики та створили візуалізації для виявлення шахрайських заяв за допомогою служб AWS Analytics.

Ми рекомендуємо переглянути розділи безпеки в Текст Amazon, «Амазонка» та Amazon A2I документацію та дотримання наданих інструкцій. Щоб дізнатися більше про ціни на рішення, перегляньте інформацію про ціни Текст Amazon, «Амазонка» та Amazon A2I.

Про авторів

Чінмаї Рейн є архітектором спеціалістів із штучного інтелекту та ML в Amazon Web Services. Вона захоплюється прикладною математикою та машинним навчанням. Вона зосереджується на розробці інтелектуальних рішень для обробки документів для клієнтів AWS. Поза роботою вона любить танцювати сальсу та бачату.

Удай Нараянан є архітектором аналітичних рішень в AWS. Йому подобається допомагати клієнтам знаходити інноваційні рішення складних бізнес-завдань. Основні сфери його діяльності – аналіз даних, системи великих даних і машинне навчання. У вільний час любить займатися спортом, дивитися серіали та подорожувати.

Соналі Саху очолює групу архітекторів рішень Intelligent Document Processing AI/ML Solutions в Amazon Web Services. Вона є пристрасним технофілом і любить працювати з клієнтами над вирішенням складних проблем за допомогою інновацій. Її основний напрямок — штучний інтелект і машинне навчання для інтелектуальної обробки документів.