עיבוד מסמכים חכם עם שירותי AWS AI ו-Analytics בתעשיית הביטוח: חלק 2

In חלק 1 מתוך סדרה זו, דנו בעיבוד מסמכים חכם (IDP), וכיצד IDP יכול להאיץ מקרי שימוש בעיבוד תביעות בענף הביטוח. דנו כיצד אנו יכולים להשתמש בשירותי AI של AWS כדי לסווג במדויק מסמכי תביעה יחד עם מסמכים תומכים. דנו גם כיצד לחלץ סוגים שונים של מסמכים בחבילת תביעות ביטוח, כגון טפסים, טבלאות או מסמכים מיוחדים כגון חשבוניות, קבלות או תעודות זהות. בדקנו את האתגרים בתהליכי מסמכים מדור קודם, שהם גוזלים זמן רב, מועדים לשגיאות, יקרים וקשים לעיבוד בקנה מידה, וכיצד אתה יכול להשתמש בשירותי AI של AWS כדי לסייע ביישום צינור ה-IDP שלך.

בפוסט זה, אנו מדריכים אותך דרך תכונות IDP מתקדמות לחילוץ מסמכים, שאילתות והעשרה. אנו גם בודקים כיצד להמשיך להשתמש במידע המובנה שחולץ מנתוני תביעות כדי לקבל תובנות באמצעות AWS Analytics ושירותי הדמיה. אנו מדגישים כיצד נתונים מובנים שחולצו מ-IDP יכולים לעזור נגד תביעות הונאה באמצעות שירותי AWS Analytics.

סקירת פתרונות

התרשים הבא ממחיש את השלבים של IDP באמצעות שירותי AI של AWS. בחלק 1, דנו בשלושת השלבים הראשונים של זרימת העבודה של IDP. בפוסט זה נרחיב על שלב החילוץ והשלבים הנותרים, הכוללים שילוב IDP עם שירותי AWS Analytics.

אנו משתמשים בשירותי הניתוח הללו לתובנות נוספות ולהדמיות, וכדי לזהות תביעות הונאה באמצעות נתונים מובנים ומנורמלים מ-IDP. התרשים הבא ממחיש את ארכיטקטורת הפתרון.

השלבים בהם אנו דנים בפוסט זה משתמשים בשירותי המפתח הבאים:

• אמזון Comprehend Medical הוא שירות עיבוד שפה טבעית (NLP) התאמת HIPAA המשתמש במודלים של למידת מכונה (ML) שהוכשרו מראש כדי להבין ולחלץ נתוני בריאות מטקסט רפואי, כגון מרשמים, נהלים או אבחנות.
• דבק AWS הוא חלק מחסנית שירותי AWS Analytics, והוא שירות שילוב נתונים ללא שרת המקל על גילוי, הכנה ושילוב של נתונים עבור ניתוח, ML ופיתוח יישומים.
• האדום של אמזון הוא שירות נוסף בערימת Analytics. Amazon Redshift הוא שירות מחסן נתונים בקנה מידה פטה-בייט מנוהל במלואו בענן.

תנאים מוקדמים

לפני שתתחיל, עיין ב חלק 1 לסקירה ברמה גבוהה של מקרה השימוש בביטוח עם IDP ופרטים על שלבי לכידת הנתונים והסיווג.

למידע נוסף לגבי דוגמאות הקוד, עיין בכתובת שלנו ריפו GitHub.

שלב המיצוי

בחלק 1, ראינו כיצד להשתמש בממשקי API של Amazon Textract כדי לחלץ מידע כמו טפסים וטבלאות ממסמכים, וכיצד לנתח חשבוניות ומסמכי זהות. בפוסט זה, אנו משפרים את שלב החילוץ עם Amazon Comprehend כדי לחלץ ישויות ברירת מחדל וישויות מותאמות אישית ספציפיות למקרי שימוש מותאמים אישית.

חברות ביטוח נתקלות לעתים קרובות בטקסט צפוף בבקשות לתביעות ביטוח, כגון מכתב סיכום שחרור של מטופל (ראה תמונה לדוגמה הבאה). זה יכול להיות קשה לחלץ מידע אוטומטי מסוגים כאלה של מסמכים שבהם אין מבנה מוגדר. כדי לטפל בזה, אנו יכולים להשתמש בשיטות הבאות כדי לחלץ מידע עסקי מרכזי מהמסמך:

חלץ ישויות ברירת מחדל עם ה-API של Amazon Comprehend DetectEntities

אנו מריצים את הקוד הבא על מסמך התמלול הרפואי לדוגמה:

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)

צילום המסך הבא מציג את התוצאות שלנו.

שלב העשרה

בשלב העשרת המסמכים, אנו מבצעים פונקציות העשרה במסמכים הקשורים לטיפול רפואי כדי להפיק תובנות חשובות. אנו בוחנים את סוגי ההעשרה הבאים:

• חלץ שפה ספציפית לדומיין - אנו משתמשים באמזון 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 Textract DetectDocumentText API, ה InferICD10CM API מחזיר את הפלט הבא (הפלט קוצר לקיצור).

באופן דומה, אנו יכולים להשתמש ב- Amazon Comprehend Medical InferRxNorm API לזיהוי תרופות ואת InferSNOMEDCT API לאיתור ישויות רפואיות בתוך מסמכי ביטוח הקשורים לבריאות.

בצע עריכת PII ו-PHI

חבילות תביעות ביטוח דורשות הרבה תאימות ותקנות לפרטיות מכיוון שהן מכילות גם נתוני PII וגם PHI. ספקי ביטוח יכולים להפחית את סיכון התאימות על ידי תיקון מידע כמו מספרי פוליסה או שם המטופל.

בואו נסתכל על דוגמה לסיכום שחרור של מטופל. אנו משתמשים ב- Amazon Comprehend DetectPiiEntities API לאיתור ישויות PII בתוך המסמך ולהגן על פרטיות המטופל על ידי עריכת ישויות אלה:

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)

אנו מקבלים את הישויות PII הבאות בתגובה מה- detect_pii_entities() ממשק API:

לאחר מכן נוכל לתקן את ישויות ה-PII שזוהו מהמסמכים על ידי שימוש בגיאומטריית התיבה התוחמת של הישויות מהמסמך. לשם כך, אנו משתמשים בכלי עוזר שנקרא amazon-textract-overlayer. למידע נוסף, עיין ב Textract-שכבת-על. צילומי המסך הבאים משווים מסמך לפני ואחרי עריכה.

דומה ל- Amazon Comprehend DetectPiiEntities API, אנחנו יכולים גם להשתמש ב- DetectPHI API לזיהוי נתוני PHI בטקסט הקליני הנבדק. למידע נוסף, עיין ב גלה PHI.

שלב סקירה ואימות

בשלב סקירת ותיקוף המסמכים נוכל כעת לוודא אם חבילת התביעה עומדת בדרישות העסק, מכיוון שברשותנו כל המידע שנאסף מהמסמכים בחבילה משלבים מוקדמים יותר. אנו יכולים לעשות זאת על ידי הצגת אדם במעגל שיכול לסקור ולאמת את כל השדות או רק תהליך אישור אוטומטי לתביעות בדולר נמוך לפני שליחת החבילה ליישומים במורד הזרם. אנחנו יכולים להשתמש אמזון AI מוגדל (Amazon A2I) לאוטומציה של תהליך הבדיקה האנושית לעיבוד תביעות ביטוח.

כעת, כאשר כל הנתונים הנדרשים נשאבו ונורמלו מעיבוד תביעות באמצעות שירותי AI עבור IDP, אנו יכולים להרחיב את הפתרון לשילוב עם שירותי AWS Analytics כגון AWS Glue ו-Amazon Redshift כדי לפתור מקרי שימוש נוספים ולספק ניתוחים והדמיות נוספות.

איתור תביעות ביטוח הונאה

בפוסט זה, אנו מיישמים ארכיטקטורה ללא שרת שבה הנתונים המחולצים והמעובדים מאוחסנים באגם נתונים ומשמשים לאיתור תביעות ביטוח הונאה באמצעות ML. אנו משתמשים שירות אחסון פשוט של אמזון (Amazon S3) לאחסון הנתונים המעובדים. אז נוכל להשתמש דבק AWS or אמזון EMR כדי לנקות את הנתונים ולהוסיף שדות נוספים כדי להפוך אותם לצריכים עבור דיווח ו-ML. לאחר מכן, אנו משתמשים אמזון Redshift ML לבנות מודל ML לגילוי הונאה. לבסוף, אנו בונים דוחות באמצעות אמזון קוויקסייט כדי לקבל תובנות על הנתונים.

הגדר סכימה חיצונית של Amazon Redshift

לצורך דוגמה זו, יצרנו א מערך לדוגמה המחקה את הפלט של תהליך ETL (חילוץ, טרנספורמציה וטעינה), והשתמש ב-AWS Glue Data Catalog כקטלוג המטא נתונים. ראשית, אנו יוצרים מסד נתונים בשם idp_demo בקטלוג הנתונים וסכימה חיצונית באמזון Redshift שנקראת idp_insurance_demo (ראה את הקוד הבא). אנו משתמשים ב- AWS זהות וניהול גישה תפקיד (IAM) להעניק הרשאות לאשכול האדום של אמזון לגשת לאמזון S3 ו אמזון 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

השלב הבא הוא יצירת טבלה חיצונית באמזון 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, המורכב מכל הרשומות עם מזהה <= 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 המורכב מכל הרשומות עם מזהה >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 השולחן.

דמיין את נתוני התביעות

כאשר הנתונים זמינים באמזון Redshift, אנו יכולים ליצור הדמיות באמצעות QuickSight. לאחר מכן נוכל לשתף את לוחות המחוונים של QuickSight עם משתמשים עסקיים ואנליסטים. כדי ליצור את לוח המחוונים של QuickSight, תחילה עליך ליצור מערך נתונים של Amazon Redshift ב-QuickSight. להנחיות, עיין ב יצירת מערך נתונים ממסד נתונים.

לאחר יצירת מערך הנתונים, תוכל ליצור ניתוח חדש ב-QuickSight באמצעות מערך הנתונים. להלן כמה דוחות לדוגמה שיצרנו:

• המספר הכולל של תביעות לפי מדינה, מקובצות לפי fraud שדה – תרשים זה מציג לנו את השיעור של עסקאות הונאה בהשוואה למספר הכולל של עסקאות במדינה מסוימת.
• סכום הערך הדולר הכולל של התביעות, מקובצות לפי fraud שדה – תרשים זה מציג לנו את השיעור של סכום הדולר של עסקאות הונאה בהשוואה לסכום הדולר הכולל של העסקאות במדינה מסוימת.
• סך כל העסקאות לכל חברת ביטוח, מקובצות לפי fraud שדה – תרשים זה מראה לנו כמה תביעות הוגשו עבור כל חברת ביטוח וכמה מהן הן הונאה.

• הסכום הכולל של עסקאות הונאה לפי מדינה המוצג על מפת ארה"ב - תרשים זה רק מציג את העסקאות ההונאה ומציג את סך כל החיובים עבור אותן עסקאות לפי מדינה על המפה. הגוון הכהה יותר של הכחול מצביע על סך טעינות גבוהות יותר. אנו יכולים להמשיך לנתח זאת לפי עיר באותה מדינה ומיקוד עם העיר כדי להבין טוב יותר את המגמות.

לנקות את

כדי למנוע חיובים עתידיים לחשבון AWS שלך, מחק את המשאבים שסיפקת בהגדרה על ידי ביצוע ההוראות ב- סעיף ניקיון בריפו שלנו.

סיכום

בסדרה זו בת שני חלקים, ראינו כיצד לבנות צינור IDP מקצה לקצה עם ניסיון מועט או ללא ניסיון ב-ML. בדקנו מקרה שימוש בעיבוד תביעות בתעשיית הביטוח וכיצד IDP יכול לעזור לאוטומטי של מקרה שימוש זה באמצעות שירותים כגון Amazon Textract, Amazon Comprehend, Amazon Comprehend Medical ואמזון A2I. בחלק 1, הדגמנו כיצד להשתמש בשירותי AI של AWS לחילוץ מסמכים. בחלק 2, הרחבנו את שלב החילוץ וביצענו העשרת נתונים. לבסוף, הרחבנו את הנתונים המובנים שחולצו מ-IDP לניתוח נוסף, ויצרנו הדמיות לזיהוי תביעות הונאה באמצעות שירותי AWS Analytics.

אנו ממליצים לסקור את סעיפי האבטחה של טקסטורה באמזון, אמזון להתבונן, ו אמזון A2I תיעוד וביצוע ההנחיות שסופקו. למידע נוסף על התמחור של הפתרון, עיין בפרטי התמחור של טקסטורה באמזון, אמזון להתבונן, ו אמזון A2I.

על הכותבים

צ'ינמיי ראן הוא אדריכל פתרונות AI/ML מומחה בשירותי האינטרנט של אמזון. היא נלהבת למתמטיקה שימושית ולמידת מכונה. היא מתמקדת בעיצוב פתרונות עיבוד מסמכים חכמים עבור לקוחות AWS. מחוץ לעבודה, היא נהנית לרקוד סלסה ובאצ'טה.

אודאי נאריאנן הוא אדריכל פתרונות מומחה ב-Analytics ב-AWS. הוא נהנה לעזור ללקוחות למצוא פתרונות חדשניים לאתגרים עסקיים מורכבים. תחומי הליבה שלו הם ניתוח נתונים, מערכות ביג דאטה ולמידת מכונה. בזמנו הפנוי הוא נהנה לשחק ספורט, לצפות בתוכניות טלוויזיה ולטייל.

סונאלי סהו מובילה את צוות האדריכלים Intelligent Document Processing AI/ML Solutions ב- Amazon Web Services. היא טכנופילית נלהבת ונהנית לעבוד עם לקוחות כדי לפתור בעיות מורכבות באמצעות חדשנות. תחום הליבה שלה הוא בינה מלאכותית ולמידת מכונה לעיבוד מסמכים חכם.