Intelligente Dokumentenverarbeitung mit AWS AI- und Analytics-Services in der Versicherungsbranche: Teil 2

In Teil 1 In dieser Serie haben wir über intelligente Dokumentenverarbeitung (IDP) gesprochen und darüber, wie IDP Anwendungsfälle für die Schadensbearbeitung in der Versicherungsbranche beschleunigen kann. Wir haben besprochen, wie wir AWS AI-Services verwenden können, um Anspruchsdokumente zusammen mit unterstützenden Dokumenten genau zu kategorisieren. Wir haben auch besprochen, wie verschiedene Arten von Dokumenten aus einem Paket mit Versicherungsansprüchen extrahiert werden können, z. B. Formulare, Tabellen oder spezielle Dokumente wie Rechnungen, Quittungen oder Ausweisdokumente. Wir haben uns mit den Herausforderungen bei Legacy-Dokumentprozessen befasst, die zeitaufwändig, fehleranfällig, teuer und schwierig in großem Umfang zu verarbeiten sind, und wie Sie AWS-KI-Services nutzen können, um Ihre IDP-Pipeline zu implementieren.

In diesem Beitrag führen wir Sie durch erweiterte IDP-Funktionen zum Extrahieren, Abfragen und Anreichern von Dokumenten. Wir untersuchen auch, wie die extrahierten strukturierten Informationen aus Schadensdaten weiter verwendet werden können, um mithilfe von AWS Analytics und Visualisierungsservices Einblicke zu erhalten. Wir heben hervor, wie extrahierte strukturierte Daten von IDP mithilfe von AWS Analytics-Services gegen betrügerische Ansprüche helfen können.

Lösungsüberblick

Das folgende Diagramm veranschaulicht die Phasen, wenn IDP AWS AI-Services verwendet. In Teil 1 haben wir die ersten drei Phasen des IDP-Workflows besprochen. In diesem Beitrag gehen wir auf den Extraktionsschritt und die verbleibenden Phasen ein, zu denen die Integration von IDP mit AWS Analytics-Services gehört.

Wir verwenden diese Analysedienste für weitere Einblicke und Visualisierungen und um betrügerische Ansprüche anhand strukturierter, normalisierter Daten von IDP zu erkennen. Das folgende Diagramm veranschaulicht die Lösungsarchitektur.

Die Phasen, die wir in diesem Beitrag besprechen, verwenden die folgenden Schlüsseldienste:

• Amazon begreifen medizinische ist ein HIPAA-fähiger Dienst zur Verarbeitung natürlicher Sprache (NLP), der Modelle für maschinelles Lernen (ML) verwendet, die vortrainiert wurden, um Gesundheitsdaten aus medizinischen Texten wie Verschreibungen, Verfahren oder Diagnosen zu verstehen und zu extrahieren.
• AWS-Kleber ist Teil des AWS Analytics-Service-Stacks und ein serverloser Datenintegrationsservice, der das Auffinden, Vorbereiten und Kombinieren von Daten für Analysen, ML und Anwendungsentwicklung erleichtert.
• Amazon RedShift ist ein weiterer Dienst im Analytics-Stack. Amazon Redshift ist ein vollständig verwalteter Data Warehouse-Service im Petabyte-Bereich in der Cloud.

Voraussetzungen:

Bevor Sie beginnen, lesen Sie unter Teil 1 für einen allgemeinen Überblick über den Versicherungsanwendungsfall mit IDP und Details zu den Phasen der Datenerfassung und -klassifizierung.

Weitere Informationen zu den Codebeispielen finden Sie in unserer GitHub Repo.

Extraktionsphase

In Teil 1 haben wir gesehen, wie man Amazon Textract-APIs verwendet, um Informationen wie Formulare und Tabellen aus Dokumenten zu extrahieren und wie man Rechnungen und Ausweisdokumente analysiert. In diesem Beitrag erweitern wir die Extraktionsphase mit Amazon Comprehend, um standardmäßige und benutzerdefinierte Entitäten zu extrahieren, die für benutzerdefinierte Anwendungsfälle spezifisch sind.

Versicherungsträger stoßen in Anträgen auf Versicherungsansprüche häufig auf dichten Text, wie z. B. den zusammenfassenden Entlassungsbrief eines Patienten (siehe folgendes Beispielbild). Es kann schwierig sein, Informationen automatisch aus Dokumenten dieser Art zu extrahieren, wenn es keine bestimmte Struktur gibt. Um dies zu beheben, können wir die folgenden Methoden verwenden, um wichtige Geschäftsinformationen aus dem Dokument zu extrahieren:

Extrahieren Sie Standardentitäten mit der Amazon Comprehend DetectEntities-API

Wir führen den folgenden Code auf dem Beispieldokument für die medizinische Transkription aus:

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

Der folgende Screenshot zeigt eine Sammlung von Entitäten, die im Eingabetext identifiziert wurden. Die Ausgabe wurde für die Zwecke dieses Beitrags gekürzt. Beziehen Sie sich auf die GitHub Repo für eine detaillierte Liste der Entitäten.

Extrahieren Sie benutzerdefinierte Entitäten mit der Erkennung benutzerdefinierter Entitäten von Amazon Comprehend

Die Antwort von der DetectEntities Die API enthält die Standardentitäten. Wir sind jedoch daran interessiert, bestimmte Entitätswerte zu kennen, wie z. B. den Namen des Patienten (gekennzeichnet durch die Standardentität PERSON) oder die Patienten-ID (gekennzeichnet durch die Standardentität OTHER). Um diese benutzerdefinierten Entitäten zu erkennen, trainieren wir ein Amazon Comprehend-Erkennungsmodell für benutzerdefinierte Entitäten. Wir empfehlen, die umfassenden Schritte zum Trainieren und Bereitstellen eines benutzerdefinierten Entitätserkennungsmodells in der zu befolgen GitHub Repo.

Nachdem wir das benutzerdefinierte Modell bereitgestellt haben, können wir die Hilfsfunktion verwenden get_entities() um benutzerdefinierte Entitäten wie abzurufen PATIENT_NAME und PATIENT_D aus der API-Antwort:

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)

Der folgende Screenshot zeigt unsere Ergebnisse.

Anreicherungsphase

In der Dokumentenanreicherungsphase führen wir Anreicherungsfunktionen für gesundheitsbezogene Dokumente durch, um wertvolle Erkenntnisse zu gewinnen. Wir betrachten folgende Arten der Anreicherung:

• Domänenspezifische Sprache extrahieren – Wir verwenden Amazon Comprehend Medical, um medizinspezifische Ontologien wie ICD-10-CM, RxNorm und SNOMED CT zu extrahieren
• Vertrauliche Informationen schwärzen – Wir verwenden Amazon Comprehend, um personenbezogene Daten (PII) zu schwärzen, und Amazon Comprehend Medical, um geschützte Gesundheitsinformationen (PHI) zu schwärzen

Extrahieren Sie medizinische Informationen aus unstrukturierten medizinischen Texten

Dokumente wie Notizen medizinischer Dienstleister und klinische Studienberichte enthalten dichten medizinischen Text. Versicherungsträger müssen die Beziehungen zwischen den extrahierten Gesundheitsinformationen aus diesem dichten Text identifizieren und sie mit medizinischen Ontologien wie ICD-10-CM, RxNorm und SNOMED CT-Codes verknüpfen. Dies ist sehr wertvoll bei der Automatisierung von Anspruchserfassungs-, Validierungs- und Genehmigungsworkflows für Versicherungsunternehmen, um die Anspruchsbearbeitung zu beschleunigen und zu vereinfachen. Schauen wir uns an, wie wir das Amazon Comprehend Medical verwenden können InferICD10CM API, um mögliche Erkrankungen als Entitäten zu erkennen und sie mit ihren Codes zu verknüpfen:

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

Für den Eingabetext, den wir aus dem Amazon Textract übergeben können DetectDocumentText API, die InferICD10CM Die API gibt die folgende Ausgabe zurück (die Ausgabe wurde der Kürze halber abgekürzt).

Ebenso können wir das Amazon Comprehend Medical verwenden InferRxNorm API zur Identifizierung von Medikamenten und der InferSNOMEDCT API zur Erkennung medizinischer Einheiten in krankenversicherungsbezogenen Versicherungsdokumenten.

Führen Sie PII- und PHI-Schwärzung durch

Versicherungsanspruchspakete erfordern eine Menge Datenschutzkonformität und Vorschriften, da sie sowohl PII- als auch PHI-Daten enthalten. Versicherungsträger können das Compliance-Risiko verringern, indem sie Informationen wie Policennummern oder den Namen des Patienten unkenntlich machen.

Sehen wir uns ein Beispiel für die Entlassungsübersicht eines Patienten an. Wir verwenden das Amazon Comprehend DetectPiiEntities API zum Erkennen von PII-Entitäten innerhalb des Dokuments und zum Schutz der Privatsphäre des Patienten durch Schwärzen dieser Entitäten:

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)

Wir erhalten die folgenden PII-Entitäten in der Antwort von der detect_pii_entities() API:

Wir können dann die PII-Entitäten, die aus den Dokumenten erkannt wurden, redigieren, indem wir die Begrenzungsrahmengeometrie der Entitäten aus dem Dokument verwenden. Dafür verwenden wir ein Hilfstool namens amazon-textract-overlayer. Weitere Informationen finden Sie unter Texttrakt-Overlayer. Die folgenden Screenshots vergleichen ein Dokument vor und nach der Schwärzung.

Ähnlich wie Amazon Comprehend DetectPiiEntities API können wir auch die verwenden DetectPHI API zur Erkennung von PHI-Daten im untersuchten klinischen Text. Weitere Informationen finden Sie unter PHI erkennen.

Überprüfungs- und Validierungsphase

In der Phase der Dokumentenprüfung und -validierung können wir jetzt überprüfen, ob das Anspruchspaket den Anforderungen des Unternehmens entspricht, da wir alle Informationen haben, die aus den Dokumenten in den Paketen aus früheren Phasen gesammelt wurden. Wir können dies tun, indem wir einen Menschen in die Schleife einführen, der alle Felder überprüfen und validieren kann, oder einfach einen automatischen Genehmigungsprozess für Forderungen mit geringem Geldbetrag, bevor das Paket an nachgelagerte Anwendungen gesendet wird. Wir können benutzen Amazon Augmented AI (Amazon A2I), um den menschlichen Überprüfungsprozess für die Bearbeitung von Versicherungsansprüchen zu automatisieren.

Jetzt, da wir alle erforderlichen Daten aus der Schadenbearbeitung mithilfe von KI-Services für IDP extrahiert und normalisiert haben, können wir die Lösung erweitern, um sie in AWS Analytics-Services wie AWS Glue und Amazon Redshift zu integrieren, um zusätzliche Anwendungsfälle zu lösen und weitere Analysen und Visualisierungen bereitzustellen.

Erkennen Sie betrügerische Versicherungsansprüche

In diesem Beitrag implementieren wir eine serverlose Architektur, bei der die extrahierten und verarbeiteten Daten in einem Data Lake gespeichert und zur Erkennung betrügerischer Versicherungsansprüche mithilfe von ML verwendet werden. Wir gebrauchen Amazon Simple Storage-Service (Amazon S3) zur Speicherung der verarbeiteten Daten. Wir können dann verwenden AWS-Kleber or Amazon EMR um die Daten zu bereinigen und zusätzliche Felder hinzuzufügen, um sie für Berichte und ML nutzbar zu machen. Danach verwenden wir Amazon Redshift ML um ein ML-Modell zur Betrugserkennung zu erstellen. Schließlich erstellen wir Berichte mit Amazon QuickSight um Einblicke in die Daten zu erhalten.

Richten Sie das externe Amazon Redshift-Schema ein

Für dieses Beispiel haben wir eine erstellt Beispieldatensatz emuliert die Ausgabe eines ETL-Prozesses (Extrahieren, Transformieren und Laden) und verwendet AWS Glue Data Catalog als Metadatenkatalog. Zuerst erstellen wir eine Datenbank mit dem Namen idp_demo im Data Catalog und ein externes Schema in Amazon Redshift aufgerufen idp_insurance_demo (siehe folgenden Code). Wir verwenden ein AWS Identity and Access Management and (IAM)-Rolle, um dem Amazon Redshift-Cluster Berechtigungen für den Zugriff auf Amazon S3 und Amazon Sage Maker. Weitere Informationen zum Einrichten dieser IAM-Rolle mit den geringsten Rechten finden Sie unter Clustern und konfigurieren Sie die Einrichtung für die Amazon Redshift ML-Verwaltung.

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

Erstellen Sie eine externe Amazon Redshift-Tabelle

Der nächste Schritt besteht darin, eine externe Tabelle in Amazon Redshift zu erstellen, die auf den S3-Speicherort verweist, an dem sich die Datei befindet. In diesem Fall ist unsere Datei eine kommaseparierte Textdatei. Wir möchten auch die Kopfzeile aus der Datei überspringen, die im Abschnitt Tabelleneigenschaften konfiguriert werden kann. Siehe folgenden Code:

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

Erstellen Sie Trainings- und Testdatensätze

Nachdem wir die externe Tabelle erstellt haben, bereiten wir unseren Datensatz für ML vor, indem wir ihn in einen Trainingssatz und einen Testsatz aufteilen. Wir erstellen eine neue externe Tabelle namens claim_train, die aus allen Datensätzen mit der ID <= 85000 aus der Anspruchstabelle besteht. Dies ist das Trainingsset, auf dem wir unser ML-Modell trainieren.

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

Wir erstellen eine weitere externe Tabelle namens claim_test das aus allen Datensätzen mit der ID >85000 besteht, um das Testset zu sein, auf dem wir das ML-Modell testen:

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

Erstellen Sie ein ML-Modell mit Amazon Redshift ML

Jetzt erstellen wir das Modell mit der MODELL ERSTELLEN Befehl (siehe folgenden Code). Wir wählen die relevanten Spalten aus der aus claims_train Tabelle, die eine betrügerische Transaktion feststellen kann. Das Ziel dieses Modells ist es, den Wert vorherzusagen fraud Säule; deshalb, fraud wird als Vorhersageziel hinzugefügt. Nachdem das Modell trainiert wurde, erstellt es eine Funktion mit dem Namen insurance_fraud_model. Diese Funktion wird für Rückschlüsse verwendet, während SQL-Anweisungen ausgeführt werden, um den Wert von vorherzusagen fraud Spalte für neue Datensätze.

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

Bewerten Sie ML-Modellmetriken

Nachdem wir das Modell erstellt haben, können wir Abfragen ausführen, um die Genauigkeit des Modells zu überprüfen. Wir benutzen das insurance_fraud_model Funktion, um den Wert von vorherzusagen fraud Spalte für neue Datensätze. Führen Sie die folgende Abfrage für die aus claims_test Tabelle zum Erstellen einer Konfusionsmatrix:

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;

Erkennen Sie Betrug mit dem ML-Modell

Nachdem wir das neue Modell erstellt haben und neue Anspruchsdaten in das Data Warehouse oder den Data Lake eingefügt werden, können wir die verwenden insurance_fraud_model Funktion zur Berechnung der betrügerischen Transaktionen. Dazu laden wir zunächst die neuen Daten in eine temporäre Tabelle. Dann verwenden wir die insurance_fraud_model Funktion zur Berechnung der fraud Flag für jede neue Transaktion und fügen Sie die Daten zusammen mit dem Flag in die abschließende Tabelle ein, die in diesem Fall die ist claims Tabelle.

Visualisieren Sie die Schadensdaten

Wenn die Daten in Amazon Redshift verfügbar sind, können wir mit QuickSight Visualisierungen erstellen. Wir können die QuickSight-Dashboards dann mit Geschäftsanwendern und Analysten teilen. Um das QuickSight-Dashboard zu erstellen, müssen Sie zunächst einen Amazon Redshift-Datensatz in QuickSight erstellen. Anweisungen finden Sie unter Erstellen eines Datensatzes aus einer Datenbank.

Nachdem Sie das Dataset erstellt haben, können Sie mithilfe des Datasets eine neue Analyse in QuickSight erstellen. Im Folgenden finden Sie einige Beispielberichte, die wir erstellt haben:

• Gesamtzahl der Ansprüche nach Staat, gruppiert nach fraud Feld – Dieses Diagramm zeigt uns den Anteil betrügerischer Transaktionen im Vergleich zur Gesamtzahl der Transaktionen in einem bestimmten Bundesland.
• Summe des Dollar-Gesamtwerts der Forderungen, gruppiert nach fraud Feld – Dieses Diagramm zeigt uns den Anteil des Dollarbetrags betrügerischer Transaktionen im Vergleich zum gesamten Dollarbetrag der Transaktionen in einem bestimmten Staat.
• Gesamtzahl der Transaktionen pro Versicherungsgesellschaft, gruppiert nach der fraud Feld – Diese Grafik zeigt uns, wie viele Schadensfälle für jede Versicherungsgesellschaft eingereicht wurden und wie viele davon betrügerisch sind.

• Gesamtsumme betrügerischer Transaktionen nach Bundesstaat, angezeigt auf einer US-Karte – Dieses Diagramm zeigt nur die betrügerischen Transaktionen und zeigt die Gesamtgebühren für diese Transaktionen nach Bundesstaat auf der Karte an. Der dunklere Blauton weist auf höhere Gesamtladungen hin. Wir können dies weiter nach Stadt innerhalb dieses Staates und nach Postleitzahlen mit der Stadt analysieren, um die Trends besser zu verstehen.

Aufräumen

Um zukünftige Gebühren für Ihr AWS-Konto zu vermeiden, löschen Sie die Ressourcen, die Sie bei der Einrichtung bereitgestellt haben, indem Sie den Anweisungen in folgen Abschnitt Bereinigung in unserem Repo.

Zusammenfassung

In dieser zweiteiligen Serie haben wir gesehen, wie man mit wenig oder gar keiner ML-Erfahrung eine End-to-End-IPP-Pipeline erstellt. Wir haben einen Anwendungsfall zur Schadensbearbeitung in der Versicherungsbranche untersucht und untersucht, wie IDP dabei helfen kann, diesen Anwendungsfall mithilfe von Diensten wie Amazon Textract, Amazon Comprehend, Amazon Comprehend Medical und Amazon A2I zu automatisieren. In Teil 1 haben wir gezeigt, wie man AWS AI-Services für die Dokumentenextraktion verwendet. In Teil 2 haben wir die Extraktionsphase verlängert und eine Datenanreicherung durchgeführt. Schließlich haben wir die aus IDP extrahierten strukturierten Daten für weitere Analysen erweitert und Visualisierungen erstellt, um betrügerische Ansprüche mithilfe von AWS Analytics-Services zu erkennen.

Wir empfehlen, die Sicherheitsabschnitte der zu lesen Amazontext, Amazon verstehen und Amazon A2I Dokumentation und Einhaltung der bereitgestellten Richtlinien. Weitere Informationen zu den Preisen der Lösung finden Sie in den Preisdetails von Amazontext, Amazon verstehen und Amazon A2I.

Über die Autoren

Chinmayee Rane ist AI/ML Specialist Solutions Architect bei Amazon Web Services. Sie interessiert sich leidenschaftlich für angewandte Mathematik und maschinelles Lernen. Sie konzentriert sich auf die Entwicklung intelligenter Dokumentenverarbeitungslösungen für AWS-Kunden. Außerhalb der Arbeit tanzt sie gerne Salsa und Bachata.

Uday Narayanan ist Analytics Specialist Solutions Architect bei AWS. Es macht ihm Spaß, Kunden dabei zu helfen, innovative Lösungen für komplexe geschäftliche Herausforderungen zu finden. Seine Schwerpunkte sind Data Analytics, Big Data Systems und Machine Learning. In seiner Freizeit treibt er gerne Sport, schaut sich Serien an und reist gerne.

Sonali Sahu leitet das Team Intelligent Document Processing AI/ML Solutions Architect bei Amazon Web Services. Sie ist leidenschaftlich technikbegeistert und arbeitet gerne mit Kunden zusammen, um komplexe Probleme durch Innovation zu lösen. Ihre Kerngebiete sind künstliche Intelligenz und maschinelles Lernen für die intelligente Dokumentenverarbeitung.