Интеллектуальная обработка документов с помощью сервисов AWS AI в страховой отрасли: часть 1

Цель интеллектуальной обработки документов (IDP) — помочь вашей организации принимать более быстрые и точные решения, применяя ИИ для обработки документов. В этой серии статей, состоящей из двух частей, рассказывается о технологиях искусственного интеллекта AWS, которые страховые компании могут использовать для ускорения своих бизнес-процессов. Эти технологии искусственного интеллекта можно использовать в страховых случаях, таких как претензии, андеррайтинг, переписка с клиентами, контракты или разрешение споров. Эта серия посвящена варианту использования обработки претензий в страховой отрасли; Дополнительные сведения об основных концепциях решения AWS IDP см. в следующих документах. серия из двух частей.

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

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

Обзор решения

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

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

Решение использует следующие ключевые сервисы:

• Амазонка Текст — это служба машинного обучения (ML), которая автоматически извлекает текст, почерк и данные из отсканированных документов. Он выходит за рамки простого оптического распознавания символов (OCR) для идентификации, понимания и извлечения данных из форм и таблиц. Amazon Textract использует машинное обучение для чтения и обработки документов любого типа, точно извлекая текст, рукописный текст, таблицы и другие данные без каких-либо ручных усилий.
• Amazon Comprehend — это служба обработки естественного языка (NLP), которая использует машинное обучение для извлечения информации из текста. Amazon Comprehend может обнаруживать такие объекты, как человек, местоположение, дата, количество и т. д. Он также может определять доминирующий язык, информацию, позволяющую установить личность (PII), и классифицировать документы по соответствующему классу.
• Amazon увеличил AI (Amazon A2I) — это сервис машинного обучения, который упрощает создание рабочих процессов, необходимых для проверки человеком. Amazon A2I предоставляет всем разработчикам проверку вручную, избавляя от монотонной тяжелой работы, связанной с созданием систем проверки людьми или управлением большим количеством рецензентов. Amazon A2I интегрируется как с Амазонка Текст и Amazon Comprehend чтобы предоставить возможность ввести проверку или проверку человеком в рамках рабочего процесса IDP.

Предпосылки

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

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

Фаза сбора данных

Претензии и подтверждающие документы могут поступать по различным каналам, таким как факс, электронная почта, административный портал и т. д. Вы можете хранить эти документы в масштабируемом и надежном хранилище, таком как Простой сервис хранения Amazon (Амазон С3). Эти документы могут быть различных типов, таких как PDF, JPEG, PNG, TIFF и другие. Документы могут поступать в различных форматах и ​​макетах и ​​могут поступать в хранилище данных по разным каналам.

Этап классификации

На этапе классификации документов мы можем объединить Amazon Comprehend с Amazon Textract для преобразования текста в контекст документа для классификации документов, которые хранятся на этапе сбора данных. Затем мы можем использовать пользовательскую классификацию в Amazon Comprehend для организации документов по классам, которые мы определили в пакете обработки претензий. Пользовательская классификация также полезна для автоматизации процесса проверки документов и выявления любых отсутствующих документов в пакете. Как показано на диаграмме архитектуры, пользовательская классификация состоит из двух этапов:

1. Извлеките текст с помощью Amazon Textract из всех документов в хранилище данных, чтобы подготовить обучающие данные для пользовательского классификатора.
2. Обучите пользовательскую модель классификации Amazon Comprehend (также называемую документ классификатор) для распознавания интересующих классов на основе текстового содержимого.

После обучения пользовательской модели классификации Amazon Comprehend мы можем использовать конечную точку в реальном времени для классификации документов. Amazon Comprehend возвращает все классы документов с оценкой достоверности, связанной с каждым классом в массиве пар ключ-значение (Doc_name – Confidence_score). Мы рекомендуем ознакомиться с примером кода подробной классификации документов на GitHub.

Фаза экстракции

На этапе извлечения мы извлекаем данные из документов с помощью Amazon Textract и Amazon Comprehend. Для этого поста используйте следующие образцы документов в пакете обработки требований: форма заявления Центра услуг Medicaid и Medicare (CMS)-1500, водительские права и страховой удостоверение, а также счет-фактура.

Извлечение данных из формы претензии CMS-1500

Форма CMS-1500 — это стандартная форма заявления, используемая неинституциональным поставщиком услуг или поставщиком для выставления счетов операторам Medicare.

Важно правильно заполнить форму CMS-1500, иначе это может замедлить процесс подачи претензий или задержать оплату перевозчиком. С текстом Амазонки AnalyzeDocument API, мы можем ускорить процесс извлечения с более высокой точностью, чтобы извлечь текст из документов, чтобы понять дальнейшие идеи в форме претензии. Ниже приведен образец бланка претензии CMS-1500.

Теперь мы используем AnalyzeDocument API для извлечения двух FeatureTypes, FORMS и TABLES, из документа:

from IPython.display import display, JSON
form_resp = textract.analyze_document(Document={'S3Object':{"Bucket": data_bucket, "Name": cms_key}}, FeatureTypes=['FORMS', 'TABLES'])

# print tables
print(get_string(textract_json=form_resp, output_type=[Textract_Pretty_Print.TABLES], table_format=Pretty_Print_Table_Format.fancy_grid))

# using our constructed helper function - values returned as a dictionary

display(JSON(getformkeyvalue(form_resp), root="Claim Form"))

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

Ассоциация FORMS извлечение идентифицируется как пары ключ-значение.

Ассоциация TABLES извлечение содержит ячейки, объединенные ячейки и заголовки столбцов в обнаруженной таблице в форме утверждения.

Извлечение данных из документов, удостоверяющих личность

Для документов, удостоверяющих личность, таких как страховой удостоверение, которые могут иметь разные макеты, мы можем использовать Amazon Textract. AnalyzeDocument API. Мы используем FeatureType FORMS в качестве конфигурации для AnalyzeDocument API для извлечения пар ключ-значение из идентификатора страховки (см. следующий пример):

Запустите следующий код:

ins_form_resp = textract.analyze_document(Document={'S3Object':{"Bucket": data_bucket, "Name": ins_card_key}}, FeatureTypes=['FORMS'])

# using our constructed helper function - values returned as a dictionary

display(JSON(getformkeyvalue(ins_form_resp), root="Insurance card"))

Мы получаем пары ключ-значение в массиве результатов, как показано на следующем снимке экрана.

Для документов, удостоверяющих личность, таких как водительские права США или паспорт США, Amazon Textract предоставляет специализированную поддержку для автоматического извлечения ключевых терминов без использования шаблонов или форматов, в отличие от того, что мы видели ранее для примера страхового удостоверения. С AnalyzeID API предприятия могут быстро и точно извлекать информацию из документов, удостоверяющих личность, которые имеют разные шаблоны или форматы. AnalyzeID API возвращает две категории типов данных:

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

Мы используем следующий образец водительского удостоверения США из нашего пакета обработки претензий.

Запустите следующий код:

ID_resp = textract.analyze_id(DocumentPages=[{'S3Object':{"Bucket": data_bucket, "Name": key}}])

# once again using the textract response parser
from trp.trp2_analyzeid import TAnalyzeIdDocument, TAnalyzeIdDocumentSchema

t_doc = TAnalyzeIdDocumentSchema().load(ID_resp)

list_of_results = t_doc.get_values_as_list()
print(tabulate([x[1:3] for x in list_of_results]))

На следующем снимке экрана показан наш результат.

На скриншоте результатов видно, что представлены определенные ключи, которых не было в самом водительском удостоверении. Например, Veteran ключ не указан в лицензии; однако это предварительно заполненная пара "ключ-значение", AnalyzeID поддерживает из-за различий в лицензиях между штатами.

Извлечение данных из счетов-фактур и квитанций

Как и в случае AnalyzeID API, AnalyzeExpense API обеспечивает специализированную поддержку счетов-фактур и квитанций для извлечения соответствующей информации, такой как имя поставщика, промежуточные и общие суммы и многое другое, из документов счетов-фактур любого формата. Вам не нужен какой-либо шаблон или конфигурация для извлечения. Amazon Textract использует машинное обучение для понимания контекста неоднозначных счетов и квитанций.

Ниже приведен образец квитанции о медицинском страховании.

Мы используем AnalyzeExpense API для просмотра списка стандартизированных полей. Поля, которые не распознаются как стандартные поля, классифицируются как OTHER:

expense_resp = textract.analyze_expense(Document={'S3Object':{"Bucket": data_bucket, "Name": invc_key}})

# print invoice summary

print(get_expensesummary_string(textract_json=expense_resp, table_format=Pretty_Print_Table_Format.fancy_grid))

# print invoice line items

print(get_expenselineitemgroups_string(textract_json=expense_resp, table_format=Pretty_Print_Table_Format.fancy_grid))

Мы получаем следующий список полей в виде пар ключ-значение (см. скриншот слева) и весь ряд купленных отдельных позиций (см. скриншот справа) в результатах.

Заключение

В этом посте мы продемонстрировали распространенные проблемы при обработке претензий и то, как мы можем использовать сервисы искусственного интеллекта AWS для автоматизации интеллектуального конвейера обработки документов для автоматического рассмотрения претензии. Мы увидели, как классифицировать документы по различным классам документов с помощью пользовательского классификатора Amazon Comprehend и как использовать Amazon Textract для извлечения неструктурированных, полуструктурированных, структурированных и специализированных типов документов.

In Часть 2, мы расширяем фазу извлечения с помощью Amazon Textract. Мы также используем предопределенные и настраиваемые сущности Amazon Comprehend для обогащения данных и показываем, как расширить конвейер IDP для интеграции с сервисами аналитики и визуализации для дальнейшей обработки.

Мы рекомендуем ознакомиться с разделами безопасности Амазонский текст, Амазонка Понимание, и Амазон А2И документацию и следуя инструкциям. Чтобы узнать больше о ценах на решение, ознакомьтесь с информацией о ценах на Амазонский текст, Amazon Comprehendкачества Амазон А2И.

Об авторах

Чинмайи Ране является специалистом по архитектуре решений AI/ML в Amazon Web Services. Увлекается прикладной математикой и машинным обучением. Она занимается разработкой интеллектуальных решений для обработки документов для клиентов AWS. Вне работы она любит танцевать сальсу и бачату.

Сонали Саху возглавляет группу архитекторов решений AI/ML для интеллектуальной обработки документов в Amazon Web Services. Она страстный технофил и любит работать с клиентами для решения сложных проблем с использованием инноваций. Ее основная сфера деятельности — искусственный интеллект и машинное обучение для интеллектуальной обработки документов.

Тим Конделло — старший архитектор решений AI/ML в Amazon Web Services. Его внимание сосредоточено на обработке естественного языка и компьютерном зрении. Тиму нравится брать идеи клиентов и превращать их в масштабируемые решения.