Pemrosesan dokumen cerdas dengan layanan AWS AI dan Analytics di industri asuransi: Bagian 2

In bagian 1 dari seri ini, kami membahas pemrosesan dokumen cerdas (IDP), dan bagaimana IDP dapat mempercepat kasus penggunaan pemrosesan klaim di industri asuransi. Kami membahas bagaimana kami dapat menggunakan layanan AWS AI untuk secara akurat mengkategorikan dokumen klaim bersama dengan dokumen pendukung. Kami juga membahas cara mengekstrak berbagai jenis dokumen dalam paket klaim asuransi, seperti formulir, tabel, atau dokumen khusus seperti faktur, kwitansi, atau dokumen ID. Kami melihat tantangan dalam proses dokumen lama, yang memakan waktu, rawan kesalahan, mahal, dan sulit untuk diproses dalam skala besar, dan bagaimana Anda dapat menggunakan layanan AWS AI untuk membantu mengimplementasikan saluran IDP Anda.

Dalam posting ini, kami memandu Anda melalui fitur IDP lanjutan untuk ekstraksi dokumen, kueri, dan pengayaan. Kami juga melihat cara lebih lanjut menggunakan informasi terstruktur yang diekstraksi dari data klaim untuk mendapatkan wawasan menggunakan AWS Analytics dan layanan visualisasi. Kami menyoroti bagaimana data terstruktur yang diekstraksi dari IDP dapat membantu melawan klaim penipuan menggunakan layanan AWS Analytics.

Ikhtisar solusi

Diagram berikut mengilustrasikan fase jika IDP menggunakan layanan AWS AI. Di Bagian 1, kami membahas tiga fase pertama dari alur kerja IDP. Dalam postingan ini, kami memperluas langkah ekstraksi dan fase lainnya, yang mencakup pengintegrasian IDP dengan layanan AWS Analytics.

Kami menggunakan layanan analitik ini untuk wawasan dan visualisasi lebih lanjut, dan untuk mendeteksi klaim penipuan menggunakan data terstruktur dan dinormalisasi dari IDP. Diagram berikut menggambarkan arsitektur solusi.

Fase yang kita bahas dalam posting ini menggunakan layanan utama berikut:

• Amazon Memahami Medis adalah layanan pemrosesan bahasa alami (NLP) memenuhi syarat HIPAA yang menggunakan model pembelajaran mesin (ML) yang telah dilatih sebelumnya untuk memahami dan mengekstrak data kesehatan dari teks medis, seperti resep, prosedur, atau diagnosis.
• Lem AWS adalah bagian dari tumpukan layanan AWS Analytics, dan merupakan layanan integrasi data tanpa server yang memudahkan untuk menemukan, menyiapkan, dan menggabungkan data untuk analitik, ML, dan pengembangan aplikasi.
• Pergeseran Merah Amazon adalah layanan lain di tumpukan Analytics. Amazon Redshift adalah layanan gudang data berskala petabyte yang terkelola sepenuhnya di cloud.

Prasyarat

Sebelum Anda memulai, lihat bagian 1 untuk ikhtisar tingkat tinggi dari kasus penggunaan asuransi dengan IDP dan detail tentang pengambilan data dan tahapan klasifikasi.

Untuk informasi lebih lanjut mengenai contoh kode, lihat kami Repo GitHub.

Fase ekstraksi

Di Bagian 1, kita melihat cara menggunakan API Amazon Textract untuk mengekstrak informasi seperti formulir dan tabel dari dokumen, dan cara menganalisis faktur dan dokumen identitas. Dalam posting ini, kami meningkatkan fase ekstraksi dengan Amazon Comprehend untuk mengekstrak entitas default dan kustom khusus untuk kasus penggunaan kustom.

Operator asuransi sering menemukan teks padat dalam aplikasi klaim asuransi, seperti surat ringkasan keluar pasien (lihat contoh gambar berikut). Mungkin sulit untuk secara otomatis mengekstrak informasi dari jenis dokumen seperti itu di mana tidak ada struktur yang pasti. Untuk mengatasi ini, kita dapat menggunakan metode berikut untuk mengekstrak informasi bisnis utama dari dokumen:

Ekstrak entitas default dengan Amazon Comprehend DetectEntities API

Kami menjalankan kode berikut pada contoh dokumen transkripsi medis:

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

Tangkapan layar berikut menunjukkan kumpulan entitas yang diidentifikasi dalam teks input. Output telah dipersingkat untuk tujuan posting ini. Mengacu kepada GitHub repo untuk daftar rinci entitas.

Ekstrak entitas kustom dengan pengenalan entitas kustom Amazon Comprehend

Tanggapan dari DetectEntities API menyertakan entitas default. Namun, kami tertarik untuk mengetahui nilai entitas tertentu, seperti nama pasien (dilambangkan dengan entitas default PERSON), atau ID pasien (dilambangkan dengan entitas default OTHER). Untuk mengenali entitas kustom ini, kami melatih model pengenal entitas kustom Amazon Comprehend. Sebaiknya ikuti langkah-langkah komprehensif tentang cara melatih dan menerapkan model pengenalan entitas kustom di Repo GitHub.

Setelah kami menerapkan model khusus, kami dapat menggunakan fungsi pembantu get_entities() untuk mengambil entitas khusus seperti PATIENT_NAME dan PATIENT_D dari respons 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)

Tangkapan layar berikut menunjukkan hasil kami.

Fase pengayaan

Dalam fase pengayaan dokumen, kami melakukan fungsi pengayaan pada dokumen terkait perawatan kesehatan untuk mendapatkan wawasan yang berharga. Kami melihat jenis pengayaan berikut:

• Ekstrak bahasa khusus domain – Kami menggunakan Amazon Comprehend Medical untuk mengekstrak ontologi khusus medis seperti ICD-10-CM, RxNorm, dan SNOMED CT
• Redaksi informasi sensitif – Kami menggunakan Amazon Comprehend untuk menyunting informasi pengenal pribadi (PII), dan Amazon Comprehend Medical untuk redaksi informasi kesehatan yang dilindungi (PHI)

Ekstrak informasi medis dari teks medis tidak terstruktur

Dokumen seperti catatan penyedia medis dan laporan uji klinis menyertakan teks medis yang padat. Operator klaim asuransi perlu mengidentifikasi hubungan antara informasi kesehatan yang diekstraksi dari teks padat ini dan menautkannya ke ontologi medis seperti kode ICD-10-CM, RxNorm, dan SNOMED CT. Ini sangat berharga dalam mengotomatisasi alur kerja pengambilan, validasi, dan persetujuan klaim bagi perusahaan asuransi untuk mempercepat dan menyederhanakan pemrosesan klaim. Mari kita lihat bagaimana kita dapat menggunakan Amazon Comprehend Medical InferICD10CM API untuk mendeteksi kemungkinan kondisi medis sebagai entitas dan menautkannya ke kodenya:

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

Untuk teks input, yang dapat kami berikan dari Amazon Textract DetectDocumentText API, InferICD10CM API mengembalikan output berikut (output telah disingkat untuk singkatnya).

Demikian pula, kita dapat menggunakan Amazon Comprehend Medical InferRxNorm API untuk mengidentifikasi obat dan InferSNOMEDCT API untuk mendeteksi entitas medis dalam dokumen asuransi terkait perawatan kesehatan.

Lakukan redaksi PII dan PHI

Paket klaim asuransi membutuhkan banyak kepatuhan dan peraturan privasi karena berisi data PII dan PHI. Operator asuransi dapat mengurangi risiko kepatuhan dengan menyunting informasi seperti nomor polis atau nama pasien.

Mari kita lihat contoh ringkasan keluar pasien. Kami menggunakan Amazon Comprehend DetectPiiEntities API untuk mendeteksi entitas PII dalam dokumen dan melindungi privasi pasien dengan menyunting entitas ini:

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)

Kami mendapatkan entitas PII berikut dalam respons dari detect_pii_entities() API:

Kami kemudian dapat menyunting entitas PII yang terdeteksi dari dokumen dengan memanfaatkan geometri kotak pembatas entitas dari dokumen. Untuk itu, kami menggunakan alat pembantu yang disebut amazon-textract-overlayer. Untuk informasi lebih lanjut, lihat Textract-Overlayer. Tangkapan layar berikut membandingkan dokumen sebelum dan sesudah redaksi.

Mirip dengan Amazon Comprehend DetectPiiEntities API, kami juga dapat menggunakan DetectPHI API untuk mendeteksi data PHI dalam teks klinis yang diperiksa. Untuk informasi lebih lanjut, lihat Mendeteksi PHI.

Tahap review dan validasi

Dalam tahap peninjauan dan validasi dokumen, kami sekarang dapat memverifikasi apakah paket klaim memenuhi persyaratan bisnis, karena kami memiliki semua informasi yang dikumpulkan dari dokumen dalam paket dari tahap sebelumnya. Kita dapat melakukan ini dengan memperkenalkan manusia dalam lingkaran yang dapat meninjau dan memvalidasi semua bidang atau hanya proses persetujuan otomatis untuk klaim dolar rendah sebelum mengirim paket ke aplikasi hilir. Kita bisa menggunakan Amazon Augmented AI (Amazon A2I) untuk mengotomatiskan proses peninjauan manusia untuk pemrosesan klaim asuransi.

Sekarang setelah kami memiliki semua data yang diperlukan yang diekstraksi dan dinormalisasi dari pemrosesan klaim menggunakan layanan AI untuk IDP, kami dapat memperluas solusi untuk berintegrasi dengan layanan AWS Analytics seperti AWS Glue dan Amazon Redshift untuk menyelesaikan kasus penggunaan tambahan dan menyediakan analitik dan visualisasi lebih lanjut.

Mendeteksi klaim asuransi penipuan

Dalam posting ini, kami menerapkan arsitektur tanpa server di mana data yang diekstraksi dan diproses disimpan di danau data dan digunakan untuk mendeteksi klaim asuransi penipuan menggunakan ML. Kita gunakan Layanan Penyimpanan Sederhana Amazon (Amazon S3) untuk menyimpan data yang diproses. Kita kemudian dapat menggunakan Lem AWS or Amazon ESDM untuk membersihkan data dan menambahkan kolom tambahan agar dapat digunakan untuk pelaporan dan ML. Setelah itu, kami menggunakan Amazon Redshift ML untuk membangun model ML pendeteksi penipuan. Akhirnya, kami membuat laporan menggunakan Amazon QuickSight untuk mendapatkan wawasan tentang data.

Siapkan skema eksternal Amazon Redshift

Untuk tujuan contoh ini, kami telah membuat contoh kumpulan data mengemulasi output dari proses ETL (mengekstrak, mengubah, dan memuat), dan menggunakan Katalog Data AWS Glue sebagai katalog metadata. Pertama, kita buat database bernama idp_demo di Katalog Data dan skema eksternal di Amazon Redshift disebut idp_insurance_demo (lihat kode berikut). Kami menggunakan Identitas AWS dan Manajemen Akses (IAM) untuk memberikan izin ke klaster Amazon Redshift untuk mengakses Amazon S3 dan Amazon SageMaker. Untuk informasi selengkapnya tentang cara menyiapkan peran IAM ini dengan hak istimewa paling rendah, lihat Mengelompokkan dan mengonfigurasi penyiapan untuk administrasi Amazon Redshift ML.

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

Buat tabel eksternal Amazon Redshift

Langkah selanjutnya adalah membuat tabel eksternal di Amazon Redshift yang mereferensikan lokasi S3 tempat file berada. Dalam hal ini, file kami adalah file teks yang dipisahkan koma. Kami juga ingin melewatkan baris header dari file, yang dapat dikonfigurasi di bagian properti tabel. Lihat kode berikut:

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

Buat set data pelatihan dan pengujian

Setelah kami membuat tabel eksternal, kami menyiapkan dataset kami untuk ML dengan membaginya menjadi training set dan test set. Kami membuat tabel eksternal baru yang disebut claim_train, yang terdiri dari semua catatan dengan ID <= 85000 dari tabel klaim. Ini adalah set pelatihan tempat kami melatih model ML kami.

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

Kami membuat tabel eksternal lain yang disebut claim_test yang terdiri dari semua record dengan ID >85000 menjadi set pengujian yang kami uji model ML pada:

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

Buat model ML dengan Amazon Redshift ML

Sekarang kita membuat model menggunakan BUAT MODEL perintah (lihat kode berikut). Kami memilih kolom yang relevan dari claims_train tabel yang dapat menentukan transaksi penipuan. Tujuan dari model ini adalah untuk memprediksi nilai fraud kolom; karena itu, fraud ditambahkan sebagai target prediksi. Setelah model dilatih, ia menciptakan fungsi bernama insurance_fraud_model. Fungsi ini digunakan untuk inferensi saat menjalankan pernyataan SQL untuk memprediksi nilai dari fraud kolom untuk catatan baru.

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

Evaluasi metrik model ML

Setelah kita membuat model, kita dapat menjalankan query untuk memeriksa keakuratan model. Kami menggunakan insurance_fraud_model berfungsi untuk memprediksi nilai fraud kolom untuk catatan baru. Jalankan kueri berikut di claims_test tabel untuk membuat matriks kebingungan:

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;

Deteksi penipuan menggunakan model ML

Setelah kita membuat model baru, saat data klaim baru dimasukkan ke dalam data warehouse atau data lake, kita dapat menggunakan insurance_fraud_model berfungsi untuk menghitung transaksi penipuan. Kami melakukan ini dengan terlebih dahulu memuat data baru ke dalam tabel sementara. Kemudian kita menggunakan insurance_fraud_model fungsi untuk menghitung fraud flag untuk setiap transaksi baru dan masukkan data beserta flag tersebut ke dalam tabel final, yang dalam hal ini adalah claims tabel.

Visualisasikan data klaim

Saat data tersedia di Amazon Redshift, kita dapat membuat visualisasi menggunakan QuickSight. Kami kemudian dapat membagikan dasbor QuickSight dengan pengguna dan analis bisnis. Untuk membuat dasbor QuickSight, Anda harus terlebih dahulu membuat kumpulan data Amazon Redshift di QuickSight. Untuk petunjuk, lihat Membuat kumpulan data dari database.

Setelah Anda membuat kumpulan data, Anda dapat membuat analisis baru di QuickSight menggunakan kumpulan data. Berikut ini adalah beberapa contoh laporan yang kami buat:

• Jumlah total klaim menurut negara bagian, dikelompokkan berdasarkan fraud bidang – Bagan ini menunjukkan kepada kita proporsi transaksi penipuan dibandingkan dengan jumlah total transaksi di negara bagian tertentu.
• Jumlah total nilai dolar dari klaim, dikelompokkan berdasarkan fraud bidang – Bagan ini menunjukkan kepada kita proporsi jumlah dolar dari transaksi penipuan dibandingkan dengan jumlah total dolar transaksi di negara bagian tertentu.
• Jumlah total transaksi per perusahaan asuransi, dikelompokkan berdasarkan fraud bidang – Bagan ini menunjukkan kepada kita berapa banyak klaim yang diajukan untuk setiap perusahaan asuransi dan berapa banyak dari mereka yang curang.

• Jumlah total transaksi penipuan menurut negara bagian yang ditampilkan di peta AS – Bagan ini hanya menunjukkan transaksi penipuan dan menampilkan total biaya untuk transaksi tersebut menurut negara bagian di peta. Warna biru yang lebih gelap menunjukkan biaya total yang lebih tinggi. Kami selanjutnya dapat menganalisis ini berdasarkan kota di negara bagian itu dan kode pos dengan kota untuk lebih memahami trennya.

Membersihkan

Untuk mencegah timbulnya biaya di masa mendatang ke akun AWS Anda, hapus sumber daya yang Anda sediakan di pengaturan dengan mengikuti instruksi di Bagian pembersihan di repo kami.

Kesimpulan

Dalam seri dua bagian ini, kita melihat bagaimana membangun pipeline IDP end-to-end dengan sedikit atau tanpa pengalaman ML. Kami menjelajahi kasus penggunaan pemrosesan klaim di industri asuransi dan bagaimana IDP dapat membantu mengotomatiskan kasus penggunaan ini menggunakan layanan seperti Amazon Textract, Amazon Comprehend, Amazon Comprehend Medical, dan Amazon A2I. Di Bagian 1, kami mendemonstrasikan cara menggunakan layanan AWS AI untuk ekstraksi dokumen. Di Bagian 2, kami memperpanjang fase ekstraksi dan melakukan pengayaan data. Terakhir, kami memperluas data terstruktur yang diekstrak dari IDP untuk analisis lebih lanjut, dan membuat visualisasi untuk mendeteksi klaim penipuan menggunakan layanan AWS Analytics.

Kami merekomendasikan untuk meninjau bagian keamanan dari Teks Amazon, Amazon Comprehend, dan Amazon A2I dokumentasi dan mengikuti pedoman yang diberikan. Untuk mempelajari lebih lanjut tentang harga solusi, tinjau detail harga dari Teks Amazon, Amazon Comprehend, dan Amazon A2I.

Tentang Penulis

Chinmayee Rane adalah Arsitek Solusi Spesialis AI/ML di Amazon Web Services. Dia bersemangat tentang matematika terapan dan pembelajaran mesin. Dia berfokus pada perancangan solusi pemrosesan dokumen cerdas untuk pelanggan AWS. Di luar pekerjaan, dia menikmati tarian salsa dan bachata.

Uday Narayana adalah Arsitek Solusi Spesialis Analytics di AWS. Dia senang membantu pelanggan menemukan solusi inovatif untuk tantangan bisnis yang kompleks. Area fokus utamanya adalah analisis data, sistem data besar, dan pembelajaran mesin. Di waktu senggangnya, ia senang berolahraga, menonton acara TV, dan bepergian.

Sonali Sahu memimpin tim Intelligent Document Processing AI/ML Solutions Architect di Amazon Web Services. Dia adalah seorang technophile yang bersemangat dan senang bekerja dengan pelanggan untuk memecahkan masalah kompleks menggunakan inovasi. Area fokus utamanya adalah kecerdasan buatan dan pembelajaran mesin untuk pemrosesan dokumen cerdas.