Inteligentne przetwarzanie dokumentów z usługami AWS AI i Analytics w branży ubezpieczeniowej: Część 2

In Część 1 z tej serii omówiliśmy inteligentne przetwarzanie dokumentów (IDP) oraz sposób, w jaki IDP może przyspieszyć procesy przetwarzania roszczeń w branży ubezpieczeniowej. Omówiliśmy, w jaki sposób możemy wykorzystać usługi AWS AI do dokładnej kategoryzacji dokumentów roszczeń wraz z dokumentami pomocniczymi. Dyskutowaliśmy również o tym, jak wyodrębnić różnego rodzaju dokumenty w pakiecie szkód ubezpieczeniowych, takie jak formularze, tabele, czy dokumenty specjalistyczne, takie jak faktury, paragony czy dokumenty tożsamości. Przyjrzeliśmy się wyzwaniom związanym ze starszymi procesami związanymi z dokumentami, które są czasochłonne, podatne na błędy, drogie i trudne do przetworzenia na dużą skalę, oraz tym, jak można wykorzystać usługi AWS AI do wdrożenia potoku IDP.

W tym poście przeprowadzimy Cię przez zaawansowane funkcje IDP do ekstrakcji dokumentów, zapytań i wzbogacania. Zastanawiamy się również, jak dalej wykorzystywać wyodrębnione uporządkowane informacje z danych roszczeń, aby uzyskać wgląd w dane za pomocą AWS Analytics i usług wizualizacji. Podkreślamy, w jaki sposób wyodrębnione dane strukturalne z IDP mogą pomóc w walce z fałszywymi roszczeniami przy użyciu usług AWS Analytics.

Omówienie rozwiązania

Poniższy diagram ilustruje fazy, w których IDP korzysta z usług AWS AI. W części 1 omówiliśmy pierwsze trzy fazy przepływu pracy IDP. W tym poście rozwijamy krok ekstrakcji i pozostałe fazy, które obejmują integrację IDP z usługami AWS Analytics.

Korzystamy z tych usług analitycznych w celu uzyskania dalszych informacji i wizualizacji oraz wykrywania fałszywych roszczeń przy użyciu ustrukturyzowanych, znormalizowanych danych od dostawcy tożsamości. Poniższy diagram ilustruje architekturę rozwiązania.

Fazy, które omawiamy w tym poście, wykorzystują następujące kluczowe usługi:

• Amazon Zrozumieć Medycynę to zgodna z ustawą HIPAA usługa przetwarzania języka naturalnego (NLP), która wykorzystuje modele uczenia maszynowego (ML), które zostały wstępnie przeszkolone do rozumienia i wyodrębniania danych dotyczących zdrowia z tekstów medycznych, takich jak recepty, procedury lub diagnozy.
• Klej AWS jest częścią stosu usług AWS Analytics i jest bezserwerową usługą integracji danych, która ułatwia odkrywanie, przygotowywanie i łączenie danych na potrzeby analiz, ML i tworzenia aplikacji.
• Amazonka Przesunięcie ku czerwieni to kolejna usługa w stosie Analytics. Amazon Redshift to w pełni zarządzana usługa hurtowni danych w skali petabajta w chmurze.

Wymagania wstępne

Zanim zaczniesz, zapoznaj się z Część 1 aby uzyskać ogólny przegląd przypadku użycia w ubezpieczeniach z IDP oraz szczegóły dotyczące etapów przechwytywania i klasyfikacji danych.

Aby uzyskać więcej informacji na temat próbek kodu, zapoznaj się z naszym Repozytorium GitHub.

Faza ekstrakcji

W części 1 zobaczyliśmy, jak używać interfejsów API Amazon Texttract do wyodrębniania z dokumentów informacji, takich jak formularze i tabele, oraz jak analizować faktury i dokumenty tożsamości. W tym poście ulepszamy fazę ekstrakcji za pomocą Amazon Comprehend, aby wyodrębnić domyślne i niestandardowe encje specyficzne dla niestandardowych przypadków użycia.

Przewoźnicy ubezpieczeniowi często natrafiają na gęsty tekst we wnioskach o roszczenia ubezpieczeniowe, takie jak pismo z podsumowaniem wypisu pacjenta (patrz poniższy przykładowy obraz). Automatyczne wydobycie informacji z tego typu dokumentów może być trudne, jeśli nie ma określonej struktury. Aby rozwiązać ten problem, możemy użyć następujących metod w celu wyodrębnienia kluczowych informacji biznesowych z dokumentu:

Wyodrębnij domyślne encje za pomocą interfejsu API Amazon Comprehend DetectEntities

Na przykładowym dokumencie transkrypcji medycznej uruchamiamy następujący kod:

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"]}')

Poniższy zrzut ekranu przedstawia zbiór encji zidentyfikowanych w tekście wejściowym. Dane wyjściowe zostały skrócone na potrzeby tego postu. Zapoznaj się z GitHub repo szczegółowy wykaz podmiotów.

Wyodrębnij niestandardowe encje za pomocą niestandardowego rozpoznawania encji Amazon Comprehend

Odpowiedź od DetectEntities API zawiera encje domyślne. Interesuje nas jednak znajomość konkretnych wartości encji, takich jak imię i nazwisko pacjenta (oznaczone przez encję domyślną PERSON) lub identyfikator pacjenta (oznaczony przez jednostkę domyślną) OTHER). Aby rozpoznać te encje niestandardowe, szkolimy model rozpoznawania encji niestandardowych Amazon Comprehend. Zalecamy wykonanie kompleksowych kroków dotyczących trenowania i wdrażania niestandardowego modelu rozpoznawania jednostek w Repozytorium GitHub.

Po wdrożeniu niestandardowego modelu możemy użyć funkcji pomocniczej get_entities() do pobierania niestandardowych jednostek, takich jak PATIENT_NAME i PATIENT_D z odpowiedzi 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)

Poniższy zrzut ekranu przedstawia nasze wyniki.

Faza wzbogacania

W fazie wzbogacania dokumentów wykonujemy funkcje wzbogacania na dokumentach związanych z opieką zdrowotną, aby uzyskać cenne spostrzeżenia. Przyglądamy się następującym rodzajom wzbogacania:

• Wyodrębnij język specyficzny dla domeny – Używamy Amazon Comprehend Medical do wyodrębniania ontologii specyficznych dla medycyny, takich jak ICD-10-CM, RxNorm i SNOMED CT
• Usuń poufne informacje – Używamy Amazon Comprehend do redagowania danych osobowych (PII) oraz Amazon Comprehend Medical do redagowania chronionych informacji zdrowotnych (PHI)

Wyodrębnij informacje medyczne z nieustrukturyzowanego tekstu medycznego

Dokumenty, takie jak notatki dostawców usług medycznych i sprawozdania z badań klinicznych, zawierają gęsty tekst medyczny. Przewoźnicy odszkodowań ubezpieczeniowych muszą zidentyfikować relacje między informacjami na temat zdrowia wyodrębnionymi z tego gęstego tekstu i powiązać je z ontologiami medycznymi, takimi jak kody ICD-10-CM, RxNorm i SNOMED CT. Jest to bardzo cenne w automatyzacji procesów rejestrowania, walidacji i zatwierdzania roszczeń dla firm ubezpieczeniowych w celu przyspieszenia i uproszczenia przetwarzania roszczeń. Spójrzmy, jak możemy wykorzystać Amazon Comprehend Medical InferICD10CM API do wykrywania możliwych schorzeń jako jednostek i łączenia ich z ich kodami:

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}')

Dla tekstu wejściowego, który możemy przekazać z Amazon Text DetectDocumentText API, InferICD10CM API zwraca następujące dane wyjściowe (dane wyjściowe zostały skrócone do zwięzłości).

Podobnie możemy użyć Amazon Comprehend Medical InferRxNorm API do identyfikacji leków i InferSNOMEDCT API do wykrywania podmiotów medycznych w dokumentach ubezpieczenia zdrowotnego.

Wykonaj redakcję PII i PHI

Pakiety roszczeń ubezpieczeniowych wymagają dużej zgodności i przepisów dotyczących prywatności, ponieważ zawierają zarówno dane PII, jak i PHI. Przewoźnicy ubezpieczeniowi mogą zmniejszyć ryzyko braku zgodności, redagując informacje, takie jak numery polis lub nazwisko pacjenta.

Spójrzmy na przykład podsumowania wypisu pacjenta. Używamy Amazon Zrozumieć DetectPiiEntities API do wykrywania jednostek PII w dokumencie i ochrony prywatności pacjenta poprzez redagowanie tych jednostek:

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)

W odpowiedzi otrzymamy następujące podmioty PII od detect_pii_entities() API:

Następnie możemy zredagować elementy umożliwiające identyfikację osoby, które zostały wykryte w dokumentach, wykorzystując geometrię obwiedni elementów z dokumentu. W tym celu używamy narzędzia pomocniczego o nazwie amazon-textract-overlayer. Aby uzyskać więcej informacji, zobacz Tekst-Nakładka. Poniższe zrzuty ekranu porównują dokument przed redakcją i po niej.

Podobny do Amazona Zrozumieć DetectPiiEntities API, możemy również użyć DetectPHI API do wykrywania danych PHI w badanym tekście klinicznym. Aby uzyskać więcej informacji, zobacz Wykryj PHI.

Faza przeglądu i walidacji

W fazie przeglądu i walidacji dokumentów możemy teraz zweryfikować, czy pakiet roszczeń spełnia wymagania biznesowe, ponieważ mamy wszystkie informacje zebrane z dokumentów w pakiecie z wcześniejszych etapów. Możemy to zrobić, wprowadzając w pętlę człowieka, który może przeglądać i weryfikować wszystkie pola lub po prostu proces automatycznego zatwierdzania roszczeń o niskiej wartości przed wysłaniem pakietu do dalszych aplikacji. Możemy użyć Amazon AI Augmented (Amazon A2I) w celu zautomatyzowania procesu oceny przez człowieka w zakresie przetwarzania roszczeń ubezpieczeniowych.

Teraz, gdy mamy już wszystkie wymagane dane wyodrębnione i znormalizowane z przetwarzania roszczeń za pomocą usług AI dla IDP, możemy rozszerzyć rozwiązanie o integrację z usługami AWS Analytics, takimi jak AWS Glue i Amazon Redshift, aby rozwiązać dodatkowe przypadki użycia i zapewnić dalsze analizy i wizualizacje.

Wykryj fałszywe roszczenia ubezpieczeniowe

W tym poście wdrażamy architekturę bezserwerową, w której wyodrębnione i przetworzone dane są przechowywane w jeziorze danych i są wykorzystywane do wykrywania fałszywych roszczeń ubezpieczeniowych za pomocą ML. Używamy Usługa Amazon Simple Storage (Amazon S3) do przechowywania przetworzonych danych. Możemy wtedy użyć Klej AWS or Amazon EMR aby wyczyścić dane i dodać dodatkowe pola, aby można było je wykorzystać do raportowania i ML. Następnie używamy Amazon Redshift ML zbudować model wykrywania oszustw ML. Na koniec budujemy raporty za pomocą Amazon QuickSight aby uzyskać wgląd w dane.

Skonfiguruj zewnętrzny schemat Amazon Redshift

Na potrzeby tego przykładu stworzyliśmy przykładowy zbiór danych emuluje dane wyjściowe procesu ETL (wyodrębnianie, przekształcanie i ładowanie) i używa katalogu danych kleju AWS jako katalogu metadanych. Najpierw tworzymy bazę danych o nazwie idp_demo w Data Catalog i zewnętrznym schemacie w Amazon Redshift o nazwie idp_insurance_demo (patrz poniższy kod). Używamy an AWS Zarządzanie tożsamością i dostępem Rola (IAM) do przyznawania uprawnień do klastra Amazon Redshift w celu uzyskania dostępu do Amazon S3 i Amazon Sage Maker. Aby uzyskać więcej informacji o tym, jak skonfigurować tę rolę uprawnień z najmniejszymi uprawnieniami, zobacz Klaster i konfiguracja konfiguracji dla administracji Amazon Redshift ML.

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

Utwórz zewnętrzną tabelę Amazon Redshift

Następnym krokiem jest utworzenie zewnętrznej tabeli w Amazon Redshift odwołującej się do lokalizacji S3, w której znajduje się plik. W tym przypadku nasz plik jest plikiem tekstowym oddzielonym przecinkami. Chcemy również pominąć wiersz nagłówka z pliku, który można skonfigurować w sekcji właściwości tabeli. Zobacz następujący kod:

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');

Twórz treningowe i testowe zbiory danych

Po utworzeniu tabeli zewnętrznej przygotowujemy nasz zestaw danych dla ML, dzieląc go na zestaw treningowy i zestaw testowy. Tworzymy nową tabelę zewnętrzną o nazwie claim_train, który składa się ze wszystkich rekordów o identyfikatorze <= 85000 z tabeli oświadczeń. To jest zestaw treningowy, na którym trenujemy nasz model 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

Tworzymy kolejną zewnętrzną tabelę o nazwie claim_test który składa się ze wszystkich rekordów o ID >85000, które mają być zestawem testowym, na którym testujemy model 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

Utwórz model ML za pomocą Amazon Redshift ML

Teraz tworzymy model za pomocą UTWÓRZ MODEL polecenie (patrz poniższy kod). Wybieramy odpowiednie kolumny z claims_train tabela, która może określić fałszywą transakcję. Celem tego modelu jest przewidzenie wartości fraud kolumna; dlatego, fraud jest dodawany jako cel prognozy. Po wytrenowaniu modelu tworzy funkcję o nazwie insurance_fraud_model. Ta funkcja służy do wnioskowania podczas wykonywania instrukcji SQL w celu przewidzenia wartości fraud kolumna dla nowych rekordów.

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 '<<>>'
);

Oceń metryki modelu ML

Po utworzeniu modelu możemy uruchamiać zapytania, aby sprawdzić poprawność modelu. Używamy insurance_fraud_model funkcja do przewidywania wartości fraud kolumna dla nowych rekordów. Uruchom następujące zapytanie na claims_test tabela, aby utworzyć macierz pomyłek:

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;

Wykrywaj oszustwa za pomocą modelu ML

Po utworzeniu nowego modelu, gdy nowe dane dotyczące roszczeń są wstawiane do hurtowni danych lub jeziora danych, możemy użyć insurance_fraud_model funkcja obliczania nieuczciwych transakcji. Robimy to, najpierw ładując nowe dane do tabeli tymczasowej. Następnie używamy insurance_fraud_model funkcja do obliczania fraud flag dla każdej nowej transakcji i wstaw dane wraz z flagą do tabeli końcowej, którą w tym przypadku jest claims tabela.

Wizualizuj dane roszczeń

Gdy dane są dostępne w Amazon Redshift, możemy tworzyć wizualizacje za pomocą QuickSight. Następnie możemy udostępniać pulpity nawigacyjne QuickSight użytkownikom biznesowym i analitykom. Aby utworzyć pulpit nawigacyjny QuickSight, musisz najpierw utworzyć zestaw danych Amazon Redshift w QuickSight. Aby uzyskać instrukcje, zobacz Tworzenie zbioru danych z bazy danych.

Po utworzeniu zestawu danych możesz utworzyć nową analizę w QuickSight przy użyciu zestawu danych. Oto kilka przykładowych raportów, które stworzyliśmy:

• Całkowita liczba roszczeń według stanu, pogrupowana według fraud pole – Ten wykres pokazuje nam odsetek nieuczciwych transakcji w porównaniu z całkowitą liczbą transakcji w danym stanie.
• Suma łącznej wartości roszczeń w dolarach, pogrupowana według fraud pole – Ten wykres pokazuje nam proporcję kwoty transakcji oszukańczych w dolarach w porównaniu do łącznej kwoty transakcji w dolarach w danym stanie.
• Całkowita liczba transakcji na towarzystwo ubezpieczeniowe, pogrupowane według fraud pole – Ten wykres pokazuje nam, ile roszczeń zostało zgłoszonych do każdej firmy ubezpieczeniowej, a ile z nich jest nieuczciwych.

• Całkowita suma fałszywych transakcji według stanu wyświetlana na mapie USA – Ten wykres pokazuje tylko fałszywe transakcje i wyświetla łączne opłaty za te transakcje według stanu na mapie. Ciemniejszy odcień niebieskiego oznacza wyższe łączne ładunki. Możemy dalej analizować to według miasta w tym stanie i kodów pocztowych z miastem, aby lepiej zrozumieć trendy.

Sprzątać

Aby zapobiec naliczaniu przyszłych opłat na konto AWS, usuń zasoby, które udostępniłeś w konfiguracji, postępując zgodnie z instrukcjami w Sekcja czyszczenia w naszym repozytorium.

Wnioski

W tej dwuczęściowej serii zobaczyliśmy, jak zbudować kompleksowy potok IDP z niewielkim lub żadnym doświadczeniem w ML. Zbadaliśmy przypadek użycia przetwarzania roszczeń w branży ubezpieczeniowej oraz sposób, w jaki IDP może pomóc zautomatyzować ten przypadek użycia, korzystając z usług takich jak Amazon Text, Amazon Comprehend, Amazon Comprehend Medical i Amazon A2I. W części 1 pokazaliśmy, jak wykorzystać usługi AWS AI do ekstrakcji dokumentów. W części 2 rozszerzyliśmy fazę ekstrakcji i przeprowadziliśmy wzbogacanie danych. Na koniec rozszerzyliśmy uporządkowane dane wyodrębnione z IDP do dalszej analizy i stworzyliśmy wizualizacje do wykrywania fałszywych roszczeń za pomocą usług AWS Analytics.

Zalecamy zapoznanie się z sekcjami dotyczącymi bezpieczeństwa w Ekstrakt z amazonki, Amazon Comprehend, Amazonka A2I dokumentacji i postępując zgodnie z dostarczonymi wytycznymi. Aby dowiedzieć się więcej o cenie rozwiązania, przejrzyj szczegóły cen Ekstrakt z amazonki, Amazon Comprehend, Amazonka A2I.

O autorach

Chinmayee Rane jest specjalistą ds. rozwiązań AI/ML w Amazon Web Services. Pasjonatka matematyki stosowanej i uczenia maszynowego. Koncentruje się na projektowaniu inteligentnych rozwiązań przetwarzania dokumentów dla klientów AWS. Poza pracą lubi tańczyć salsę i bachatę.

Uday Narajana jest Architektem Rozwiązań Specjalistycznych ds. Analityki w AWS. Lubi pomagać klientom w znajdowaniu innowacyjnych rozwiązań złożonych wyzwań biznesowych. Jego główne obszary zainteresowania to analiza danych, systemy big data i uczenie maszynowe. W wolnym czasie lubi uprawiać sport, oglądać programy telewizyjne i podróżować.

Sonali Sahu kieruje zespołem Intelligent Document Processing AI/ML Solutions Architect w Amazon Web Services. Jest pasjonatką technofilki i lubi pracować z klientami przy rozwiązywaniu złożonych problemów przy użyciu innowacji. Jej głównym obszarem zainteresowania jest sztuczna inteligencja i uczenie maszynowe do inteligentnego przetwarzania dokumentów.