Intelligente documentverwerking met AWS AI en Analytics-services in de verzekeringssector: deel 2

In Deel 1 van deze serie bespraken we intelligente documentverwerking (IDP) en hoe IDP gebruiksscenario's voor claimverwerking in de verzekeringssector kan versnellen. We hebben besproken hoe we AWS AI-services kunnen gebruiken om claimdocumenten nauwkeurig te categoriseren, samen met ondersteunende documenten. We hebben ook besproken hoe u verschillende soorten documenten kunt extraheren in een pakket met verzekeringsclaims, zoals formulieren, tabellen of gespecialiseerde documenten zoals facturen, ontvangstbewijzen of ID-documenten. We hebben gekeken naar de uitdagingen in legacy documentprocessen, die tijdrovend, foutgevoelig, duur en moeilijk op grote schaal te verwerken zijn, en hoe u AWS AI-services kunt gebruiken om uw IDP-pipeline te implementeren.

In dit bericht leiden we u door geavanceerde IDP-functies voor documentextractie, query's en verrijking. We onderzoeken ook hoe we de geëxtraheerde gestructureerde informatie uit claimgegevens verder kunnen gebruiken om inzichten te krijgen met behulp van AWS Analytics en visualisatieservices. We benadrukken hoe geëxtraheerde gestructureerde gegevens van IDP kunnen helpen tegen frauduleuze claims met behulp van AWS Analytics-services.

Overzicht oplossingen

Het volgende diagram illustreert de fasen als IDP gebruikmaakt van AWS AI-services. In deel 1 hebben we de eerste drie fasen van de IDP-workflow besproken. In dit bericht gaan we dieper in op de extractiestap en de resterende fasen, waaronder de integratie van IDP met AWS Analytics-services.

We gebruiken deze analyseservices voor verdere inzichten en visualisaties en om frauduleuze claims op te sporen met behulp van gestructureerde, genormaliseerde gegevens van IDP. Het volgende diagram illustreert de oplossingsarchitectuur.

De fasen die we in dit bericht bespreken, maken gebruik van de volgende belangrijke services:

• Amazon begrijpt medisch is een voor HIPAA in aanmerking komende NLP-service (Natural Language Processing) die gebruikmaakt van machine learning-modellen (ML) die vooraf zijn getraind om gezondheidsgegevens uit medische teksten, zoals voorschriften, procedures of diagnoses, te begrijpen en te extraheren.
• AWS lijm maakt deel uit van de AWS Analytics-servicestack en is een serverloze gegevensintegratieservice waarmee u eenvoudig gegevens kunt ontdekken, voorbereiden en combineren voor analyse, ML en applicatie-ontwikkeling.
• Amazon roodverschuiving is een andere service in de Analytics-stack. Amazon Redshift is een volledig beheerde datawarehouse-service op petabyteschaal in de cloud.

Voorwaarden

Raadpleeg voordat u begint: Deel 1 voor een overzicht op hoog niveau van het verzekeringsgebruik met IDP en details over de fasen van gegevensverzameling en classificatie.

Raadpleeg voor meer informatie over de codevoorbeelden onze GitHub-opslagplaats.

Extractie fase

In deel 1 zagen we hoe we Amazon Textract API's kunnen gebruiken om informatie zoals formulieren en tabellen uit documenten te extraheren en hoe facturen en identiteitsdocumenten te analyseren. In dit bericht verbeteren we de extractiefase met Amazon Comprehend om standaard- en aangepaste entiteiten te extraheren die specifiek zijn voor aangepaste gebruiksscenario's.

Verzekeringsmaatschappijen komen vaak dichte tekst tegen in aanvragen voor verzekeringsclaims, zoals de ontslagbrief van een patiënt (zie de volgende voorbeeldafbeelding). Het kan moeilijk zijn om automatisch informatie te extraheren uit dergelijke soorten documenten waar er geen duidelijke structuur is. Om dit aan te pakken, kunnen we de volgende methoden gebruiken om belangrijke bedrijfsinformatie uit het document te extraheren:

Extraheer standaard entiteiten met de Amazon Comprehend DetectEntities API

We voeren de volgende code uit op het voorbeelddocument voor medische transcriptie:

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

De volgende schermafbeelding toont een verzameling entiteiten die in de invoertekst worden geïdentificeerd. De uitvoer is ingekort voor de doeleinden van dit bericht. Verwijs naar de GitHub repo voor een gedetailleerde lijst van entiteiten.

Extraheer aangepaste entiteiten met Amazon Comprehend-herkenning van aangepaste entiteiten

De reactie van de DetectEntities API bevat de standaardentiteiten. We zijn echter geïnteresseerd in het kennen van specifieke entiteitswaarden, zoals de naam van de patiënt (aangegeven door de standaard entiteit PERSON), of de ID van de patiënt (aangegeven door de standaard entiteit OTHER). Om deze aangepaste entiteiten te herkennen, trainen we een Amazon Comprehend-model voor het herkennen van aangepaste entiteiten. We raden u aan de uitgebreide stappen te volgen voor het trainen en implementeren van een aangepast entiteitsherkenningsmodel in de: GitHub-opslagplaats.

Nadat we het aangepaste model hebben geïmplementeerd, kunnen we de helperfunctie gebruiken get_entities() om aangepaste entiteiten op te halen zoals PATIENT_NAME en PATIENT_D uit het API-antwoord:

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)

De volgende schermafbeelding toont onze resultaten.

Verrijkingsfase

In de documentverrijkingsfase voeren we verrijkingsfuncties uit op zorggerelateerde documenten om waardevolle inzichten te verkrijgen. We kijken naar de volgende vormen van verrijking:

• Domeinspecifieke taal extraheren – We gebruiken Amazon Comprehend Medical om medisch-specifieke ontologieën zoals ICD-10-CM, RxNorm en SNOMED CT te extraheren
• Gevoelige informatie redigeren – We gebruiken Amazon Comprehend voor het redigeren van persoonlijk identificeerbare informatie (PII) en Amazon Comprehend Medical voor het redigeren van beschermde gezondheidsinformatie (PHI)

Medische informatie extraheren uit ongestructureerde medische tekst

Documenten zoals aantekeningen van medische zorgverleners en klinische onderzoeksrapporten bevatten dichte medische tekst. Vervoerders van verzekeringsclaims moeten de relaties tussen de geëxtraheerde gezondheidsinformatie uit deze dichte tekst identificeren en deze koppelen aan medische ontologieën zoals ICD-10-CM, RxNorm en SNOMED CT-codes. Dit is zeer waardevol bij het automatiseren van workflows voor het vastleggen, valideren en goedkeuren van claims voor verzekeringsmaatschappijen om claimverwerking te versnellen en te vereenvoudigen. Laten we eens kijken hoe we de Amazon Comprehend Medical kunnen gebruiken InferICD10CM API om mogelijke medische aandoeningen als entiteiten te detecteren en aan hun codes te koppelen:

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

Voor de invoertekst, die we kunnen doorgeven vanuit het Amazon Textract DetectDocumentText API, de InferICD10CM API retourneert de volgende uitvoer (de uitvoer is afgekort voor de beknoptheid).

Op dezelfde manier kunnen we de Amazon Comprehend Medical InferRxNorm API om medicijnen te identificeren en de InferSNOMEDCT API om medische entiteiten te detecteren in zorggerelateerde verzekeringsdocumenten.

PII- en PHI-redactie uitvoeren

Pakketten met verzekeringsclaims vereisen veel privacy-naleving en regelgeving omdat ze zowel PII- als PHI-gegevens bevatten. Verzekeringsmaatschappijen kunnen het nalevingsrisico verminderen door informatie zoals polisnummers of de naam van de patiënt te redigeren.

Laten we eens kijken naar een voorbeeld van een ontslagoverzicht van een patiënt. We gebruiken de Amazon Begrijpen DetectPiiEntities API om PII-entiteiten in het document te detecteren en de privacy van de patiënt te beschermen door deze entiteiten te redigeren:

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)

We krijgen de volgende PII-entiteiten in het antwoord van de detect_pii_entities() API:

We kunnen vervolgens de PII-entiteiten die in de documenten zijn gedetecteerd, redigeren door gebruik te maken van de begrenzingsvakgeometrie van de entiteiten uit het document. Daarvoor gebruiken we een hulptool genaamd amazon-textract-overlayer. Voor meer informatie, zie: Textract-Overlaag. De volgende schermafbeeldingen vergelijken een document voor en na redactie.

gelijk aan de Amazon Begrijpen DetectPiiEntities API, we kunnen ook de DetectPHI API om PHI-gegevens te detecteren in de klinische tekst die wordt onderzocht. Voor meer informatie, zie: PHI detecteren.

Beoordelings- en validatiefase

In de documentbeoordelings- en validatiefase kunnen we nu controleren of het claimpakket voldoet aan de eisen van de business, omdat we alle informatie uit eerdere stadia uit de documenten in het pakket hebben verzameld. We kunnen dit doen door een mens in de lus te introduceren die alle velden kan beoordelen en valideren, of alleen een automatisch goedkeuringsproces voor lage-dollarclaims voordat het pakket naar downstream-applicaties wordt verzonden. We kunnen gebruiken Amazon Augmented AI (Amazon A2I) om het menselijke beoordelingsproces voor de verwerking van verzekeringsclaims te automatiseren.

Nu we alle vereiste gegevens hebben geëxtraheerd en genormaliseerd uit claimverwerking met behulp van AI-services voor IDP, kunnen we de oplossing uitbreiden om te integreren met AWS Analytics-services zoals AWS Glue en Amazon Redshift om aanvullende use-cases op te lossen en verdere analyses en visualisaties te bieden.

Frauduleuze verzekeringsclaims opsporen

In dit bericht implementeren we een serverloze architectuur waarbij de geëxtraheerde en verwerkte gegevens worden opgeslagen in een datameer en worden gebruikt om frauduleuze verzekeringsclaims te detecteren met behulp van ML. We gebruiken Amazon eenvoudige opslagservice (Amazon S3) om de verwerkte gegevens op te slaan. We kunnen dan gebruik maken van AWS lijm or Amazon EMR om de gegevens op te schonen en extra velden toe te voegen om ze bruikbaar te maken voor rapportage en ML. Daarna gebruiken we Amazon RedshiftML om een ​​ML-model voor fraudedetectie te bouwen. Ten slotte bouwen we rapporten met behulp van Amazon QuickSight inzicht te krijgen in de gegevens.

Extern schema Amazon Redshift instellen

Voor dit voorbeeld hebben we een gemaakt voorbeeldgegevensset het emuleert de uitvoer van een ETL-proces (extract, transform en load) en gebruikt AWS Glue Data Catalog als de metadatacatalogus. Eerst maken we een database met de naam idp_demo in de Data Catalog en een extern schema in Amazon Redshift genaamd idp_insurance_demo (zie de volgende code). We gebruiken een AWS Identiteits- en toegangsbeheer (IAM)-rol om machtigingen te verlenen aan het Amazon Redshift-cluster voor toegang tot Amazon S3 en Amazon Sage Maker. Raadpleeg voor meer informatie over het instellen van deze IAM-rol met de minste bevoegdheden: Cluster- en configuratieconfiguratie voor Amazon Redshift ML-beheer.

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

Amazon Redshift externe tabel maken

De volgende stap is het maken van een externe tabel in Amazon Redshift die verwijst naar de S3-locatie waar het bestand zich bevindt. In dit geval is ons bestand een door komma's gescheiden tekstbestand. We willen ook de koprij uit het bestand overslaan, die kan worden geconfigureerd in het gedeelte met tabeleigenschappen. Zie de volgende 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');

Trainings- en testdatasets maken

Nadat we de externe tabel hebben gemaakt, bereiden we onze dataset voor op ML door deze op te splitsen in een trainingsset en een testset. We maken een nieuwe externe tabel met de naam claim_train, die bestaat uit alle records met ID <= 85000 uit de claimtabel. Dit is de trainingsset waarop we ons ML-model trainen.

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

We maken nog een externe tabel met de naam claim_test die bestaat uit alle records met ID >85000 om de testset te zijn waarop we het ML-model 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

Maak een ML-model met Amazon Redshift ML

Nu maken we het model met behulp van de MAAK EEN MODEL commando (zie de volgende code). We selecteren de relevante kolommen uit de claims_train tabel die een frauduleuze transactie kan bepalen. Het doel van dit model is om de waarde van de fraud kolom; daarom, fraud wordt toegevoegd als het voorspellingsdoel. Nadat het model is getraind, wordt een functie gemaakt met de naam insurance_fraud_model. Deze functie wordt gebruikt voor inferentie tijdens het uitvoeren van SQL-instructies om de waarde van de . te voorspellen fraud kolom voor nieuwe records.

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-modelstatistieken evalueren

Nadat we het model hebben gemaakt, kunnen we query's uitvoeren om de nauwkeurigheid van het model te controleren. Wij gebruiken de insurance_fraud_model functie om de waarde van de te voorspellen fraud kolom voor nieuwe records. Voer de volgende query uit op de claims_test tabel om een ​​verwarringsmatrix te maken:

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;

Fraude detecteren met het ML-model

Nadat we het nieuwe model hebben gemaakt en nieuwe claimgegevens worden ingevoegd in het datawarehouse of datameer, kunnen we de insurance_fraud_model functie om de frauduleuze transacties te berekenen. Dit doen we door eerst de nieuwe gegevens in een tijdelijke tabel te laden. Dan gebruiken we de insurance_fraud_model functie om de te berekenen fraud markeer voor elke nieuwe transactie en voeg de gegevens samen met de vlag in de finaletafel, in dit geval de claims tafel.

Visualiseer de claimgegevens

Wanneer de gegevens beschikbaar zijn in Amazon Redshift, kunnen we visualisaties maken met QuickSight. Vervolgens kunnen we de QuickSight-dashboards delen met zakelijke gebruikers en analisten. Om het QuickSight-dashboard te maken, moet u eerst een Amazon Redshift-gegevensset maken in QuickSight. Raadpleeg voor instructies: Een dataset maken vanuit een database.

Nadat u de dataset hebt gemaakt, kunt u een nieuwe analyse maken in QuickSight met behulp van de dataset. Hier volgen enkele voorbeeldrapporten die we hebben gemaakt:

• Totaal aantal claims per staat, gegroepeerd op de fraud veld- – Deze grafiek toont ons het aandeel frauduleuze transacties in vergelijking met het totale aantal transacties in een bepaalde staat.
• Som van de totale dollarwaarde van de claims, gegroepeerd op de fraud veld- - Deze grafiek toont ons het aandeel van het dollarbedrag aan frauduleuze transacties in vergelijking met het totale dollarbedrag aan transacties in een bepaalde staat.
• Totaal aantal transacties per verzekeringsmaatschappij, gegroepeerd op de fraud veld- – Deze grafiek laat zien hoeveel claims er per verzekeringsmaatschappij zijn ingediend en hoeveel frauduleus.

• Totale som van frauduleuze transacties per staat weergegeven op een kaart van de VS - Deze grafiek toont alleen de frauduleuze transacties en toont de totale kosten voor die transacties per staat op de kaart. De donkerdere tint blauw geeft hogere totale ladingen aan. We kunnen dit verder analyseren per stad binnen die staat en postcodes met de stad om de trends beter te begrijpen.

Opruimen

Om toekomstige kosten voor uw AWS-account te voorkomen, verwijdert u de bronnen die u in de configuratie hebt ingericht door de instructies in de Opruimsectie in onze repo.

Conclusie

In deze tweedelige serie hebben we gezien hoe we een end-to-end IDP-pijplijn kunnen bouwen met weinig of geen ML-ervaring. We hebben een use-case voor claimverwerking in de verzekeringssector onderzocht en hoe IDP kan helpen deze use-case te automatiseren met behulp van services zoals Amazon Textract, Amazon Comprehend, Amazon Comprehend Medical en Amazon A2I. In deel 1 hebben we laten zien hoe je AWS AI-services kunt gebruiken voor documentextractie. In deel 2 hebben we de extractiefase verlengd en gegevensverrijking uitgevoerd. Ten slotte hebben we de gestructureerde gegevens die zijn geëxtraheerd uit IDP uitgebreid voor verdere analyses en visualisaties gemaakt om frauduleuze claims te detecteren met behulp van AWS Analytics-services.

We raden u aan de beveiligingssecties van de: Amazon T-extract, Amazon begrijpt het en Amazon A2I documentatie en volgens de verstrekte richtlijnen. Voor meer informatie over de prijs van de oplossing, bekijk de prijsdetails van: Amazon T-extract, Amazon begrijpt het en Amazon A2I.

Over de auteurs

Chinmayee Rane is een AI/ML Specialist Solutions Architect bij Amazon Web Services. Ze is gepassioneerd door toegepaste wiskunde en machine learning. Ze richt zich op het ontwerpen van intelligente documentverwerkingsoplossingen voor AWS-klanten. Naast haar werk houdt ze van salsa- en bachatadansen.

Uday Narayanan is een Analytics Specialist Solutions Architect bij AWS. Hij helpt klanten graag bij het vinden van innovatieve oplossingen voor complexe zakelijke uitdagingen. Zijn belangrijkste aandachtsgebieden zijn data-analyse, big data-systemen en machine learning. In zijn vrije tijd houdt hij van sporten, tv-series kijken en reizen.

Sonali Sahu leidt het Intelligent Document Processing AI/ML Solutions Architect-team bij Amazon Web Services. Ze is een gepassioneerde technofiel en werkt graag samen met klanten om complexe problemen op te lossen met behulp van innovatie. Haar belangrijkste aandachtsgebied is kunstmatige intelligentie en machine learning voor intelligente documentverwerking.