Menggunakan AI generatif untuk pengelolaan penggunaan

Last reviewed 2024-08-19 UTC

Dokumen ini menjelaskan arsitektur referensi untuk perusahaan asuransi kesehatan yang ingin mengotomatiskan pemrosesan permintaan otorisasi sebelumnya (PA) dan meningkatkan proses peninjauan penggunaan (UR) mereka menggunakan Google Cloud. Artikel ini ditujukan untuk developer software dan administrator program di organisasi ini. Arsitektur ini membantu penyedia paket kesehatan mengurangi overhead administratif, meningkatkan efisiensi, dan meningkatkan pengambilan keputusan dengan mengotomatiskan penyerapan data dan ekstraksi insight dari formulir klinis. Hal ini juga memungkinkan mereka menggunakan model AI untuk pembuatan perintah dan rekomendasi.

Arsitektur

Diagram berikut menjelaskan arsitektur dan pendekatan untuk mengotomatiskan alur kerja penyerapan data dan mengoptimalkan proses peninjauan pengelolaan penggunaan (UM). Pendekatan ini menggunakan layanan data dan AI di Google Cloud.

Ringkasan umum proses penyerapan data dan peninjauan UM.

Arsitektur sebelumnya berisi dua alur data, yang didukung oleh subsistem berikut:

  • Claims data activator (CDA), yang mengekstrak data dari sumber tidak terstruktur, seperti formulir dan dokumen, serta menyerapnya ke dalam database dalam format terstruktur yang dapat dibaca mesin. CDA menerapkan alur data untuk menyerap formulir permintaan PA.
  • Layanan peninjauan penggunaan (layanan UR), yang mengintegrasikan data permintaan PA, dokumen kebijakan, dan panduan perawatan lainnya untuk menghasilkan rekomendasi. Layanan UR menerapkan alur data untuk meninjau permintaan PA menggunakan AI generatif.

Bagian berikut menjelaskan alur data ini.

Aliran data CDA

Diagram berikut menunjukkan alur data untuk menggunakan CDA guna menyerap formulir permintaan PA.

Aliran data pengelola kasus PA.

Seperti yang ditunjukkan pada diagram sebelumnya, pengelola kasus PA berinteraksi dengan komponen sistem untuk menyerap, memvalidasi, dan memproses permintaan PA. Pengelola kasus PA adalah individu dari tim operasi bisnis yang bertanggung jawab untuk menerima permintaan PA. Alur peristiwanya adalah sebagai berikut:

  1. Pengelola kasus PA menerima formulir permintaan PA (pa_forms) dari penyedia layanan kesehatan dan menguploadnya ke bucket Cloud Storage pa_forms_bkt.
  2. Layanan ingestion_service memproses bucket pa_forms_bkt untuk mengetahui perubahan. Layanan ingestion_service mengambil formulir pa_forms dari bucket pa_forms_bkt. Layanan ini mengidentifikasi pemroses Dokument AI yang telah dikonfigurasi sebelumnya, yang disebut form_processors. Prosesor ini ditentukan untuk memproses formulir pa_forms. Layanan ingestion_service mengekstrak informasi dari formulir menggunakan pemroses form_processors. Data yang diekstrak dari formulir dalam format JSON.
  3. Layanan ingestion_service menulis informasi yang diekstrak dengan skor keyakinan tingkat kolom ke dalam koleksi database Firestore, yang disebut pa_form_collection.
  4. Aplikasi hitl_app mengambil informasi (JSON) dengan skor keyakinan dari database pa_form_collection. Aplikasi menghitung skor keyakinan tingkat dokumen dari skor keyakinan tingkat kolom yang tersedia dalam output oleh model machine learning (ML) form_processors.
  5. Aplikasi hitl_app menampilkan informasi yang diekstrak dengan skor keyakinan tingkat kolom dan dokumen kepada pengelola kasus PA sehingga mereka dapat meninjau dan memperbaiki informasi jika nilai yang diekstrak tidak akurat. Pengelola kasus PA dapat memperbarui nilai yang salah dan menyimpan dokumen di database pa_form_collection.

Aliran data layanan UR

Diagram berikut menunjukkan aliran data untuk layanan UR.

Aliran data spesialis UR.

Seperti yang ditunjukkan pada diagram sebelumnya, spesialis UR berinteraksi dengan komponen sistem untuk melakukan peninjauan klinis atas permintaan PA. Spesialis UR biasanya adalah perawat atau dokter dengan pengalaman di area klinis tertentu yang dipekerjakan oleh perusahaan asuransi kesehatan. Alur kerja pengelolaan kasus dan pemilihan rute untuk permintaan PA berada di luar cakupan alur kerja yang dijelaskan di bagian ini.

Alur peristiwanya adalah sebagai berikut:

  1. Aplikasi ur_app menampilkan daftar permintaan PA dan status peninjauannya kepada spesialis UR. Status ditampilkan sebagai in_queue, in_progress, atau completed.
  2. Daftar dibuat dengan mengambil data pa_form information dari database pa_form_collection. Spesialis UR membuka permintaan dengan mengklik item dari daftar yang ditampilkan di aplikasi ur_app.

  3. Aplikasi ur_app mengirimkan data pa_form information ke model prompt_model. Contoh ini menggunakan Vertex AI Gemini API untuk membuat perintah yang mirip dengan berikut:

    Review a PA request for {medication|device|medical service} for our member, {Patient Name}, who is {age} old, {gender} with {medical condition}. The patient is on {current medication|treatment list}, has {symptoms}, and has been diagnosed with {diagnosis}.

  4. Aplikasi ur_app menampilkan perintah yang dihasilkan kepada spesialis UR untuk peninjauan dan masukan. Spesialis UR dapat memperbarui perintah di UI dan mengirimnya ke aplikasi.

  5. Aplikasi ur_app mengirimkan perintah ke model ur_model dengan permintaan untuk membuat rekomendasi. Model menghasilkan respons dan kembali ke aplikasi. Aplikasi menampilkan hasil yang direkomendasikan kepada spesialis UR.

  6. Spesialis UR dapat menggunakan aplikasi ur_search_app untuk menelusuri clinical documents, care guidelines, dan plan policy documents. clinical documents, care guidelines, dan plan policy documents telah diindeks sebelumnya dan dapat diakses oleh aplikasi ur_search_app.

Komponen

Arsitektur ini berisi komponen berikut:

  • Bucket Cloud Storage. Layanan aplikasi UM memerlukan bucket Cloud Storage berikut di project Google Cloud Anda:

    • pa_forms_bkt: Bucket untuk menyerap formulir PA yang memerlukan persetujuan.
    • training_forms: Bucket untuk menyimpan formulir PA historis guna melatih pemroses formulir DocAI.
    • eval_forms: Bucket untuk menyimpan formulir PA guna mengevaluasi akurasi pemroses formulir DocAI.
    • tuning_dataset: Bucket untuk menyimpan data yang diperlukan untuk menyesuaikan model bahasa besar (LLM).
    • eval_dataset: Bucket untuk menyimpan data yang diperlukan untuk mengevaluasi LLM.
    • clinical_docs: Bucket untuk menyimpan dokumen klinis yang dikirimkan penyedia sebagai lampiran ke formulir PA atau setelahnya untuk mendukung kasus PA. Dokumen ini diindeks oleh aplikasi penelusuran di layanan Vertex AI Agent Builder.
    • um_policies: Bucket untuk menyimpan panduan perawatan dan kebutuhan medis, dokumen kebijakan paket kesehatan, dan panduan cakupan. Dokumen ini diindeks oleh aplikasi penelusuran di layanan Vertex AI Agent Builder.

  • form_processors: Pemroses ini dilatih untuk mengekstrak informasi dari formulir pa_forms.

  • pa_form_collection: Datastore Firestore untuk menyimpan informasi yang diekstrak sebagai dokumen JSON dalam koleksi database NoSQL.

  • ingestion_service: Microservice yang membaca dokumen dari bucket, meneruskannya ke endpoint DocAI untuk penguraian, dan menyimpan data yang diekstrak dalam koleksi database Firestore.

  • hitl_app: Microservice (aplikasi web) yang mengambil dan menampilkan nilai data yang diekstrak dari pa_forms. Model ini juga merender skor keyakinan yang dilaporkan oleh pemroses formulir (model ML) kepada pengelola kasus PA sehingga mereka dapat meninjau, mengoreksi, dan menyimpan informasi di datastore.

  • ur_app: Microservice (aplikasi web) yang dapat digunakan spesialis UR untuk meninjau permintaan PA menggunakan AI Generatif. Model ini menggunakan model bernama prompt_model untuk membuat perintah. Microservice meneruskan data yang diekstrak dari formulir pa_forms ke model prompt_model untuk membuat perintah. Kemudian, perintah yang dihasilkan akan diteruskan ke model ur_model untuk mendapatkan rekomendasi kasus.

  • LLM Vertex AI yang disesuaikan secara medis: Vertex AI memiliki berbagai model dasar AI generatif yang dapat disesuaikan untuk mengurangi biaya dan latensi. Model yang digunakan dalam arsitektur ini adalah sebagai berikut:

    • prompt_model: Adaptor di LLM yang disesuaikan untuk menghasilkan perintah berdasarkan data yang diekstrak dari pa_forms.
    • ur_model: Adaptor di LLM yang disesuaikan untuk menghasilkan rekomendasi draf berdasarkan perintah input.

  • ur_search_app: Aplikasi penelusuran yang dibuat dengan Vertex AI Agent Builder untuk menemukan informasi yang dipersonalisasi dan relevan bagi spesialis UR dari dokumen klinis, kebijakan UM, dan pedoman cakupan.

Produk yang digunakan

Arsitektur referensi ini menggunakan produk Google Cloud berikut:

  • Vertex AI: Platform ML yang memungkinkan Anda melatih dan men-deploy model ML dan aplikasi AI, serta menyesuaikan LLM untuk digunakan dalam aplikasi yang didukung teknologi AI.
  • Vertex AI Agent Builder: Platform yang memungkinkan developer membuat dan men-deploy agen dan aplikasi yang didukung AI kelas perusahaan.
  • Document AI: Platform pemrosesan dokumen yang mengambil data tidak terstruktur dari dokumen dan mengubahnya menjadi data terstruktur.
  • Firestore: Database dokumen NoSQL yang dibuat untuk penskalaan otomatis, performa tinggi, dan kemudahan pengembangan aplikasi.
  • Cloud Run: Platform komputasi serverless yang memungkinkan Anda menjalankan container langsung di atas infrastruktur Google yang skalabel.
  • Cloud Storage: Penyimpanan objek berbiaya rendah tanpa batas untuk berbagai jenis data. Data dapat diakses dari dalam dan luar Google Cloud, serta direplikasi di seluruh lokasi untuk redundansi.
  • Cloud Logging: Sistem pengelolaan log real-time dengan penyimpanan, penelusuran, analisis, dan pemberitahuan.
  • Cloud Monitoring: Layanan yang memberikan visibilitas terkait performa, ketersediaan, dan kondisi aplikasi serta infrastruktur Anda.

Kasus penggunaan

UM adalah proses yang digunakan oleh perusahaan asuransi kesehatan terutama di Amerika Serikat, tetapi proses serupa (dengan beberapa modifikasi) digunakan secara global di pasar asuransi layanan kesehatan. Tujuan UM adalah membantu memastikan bahwa pasien menerima perawatan yang sesuai di tempat yang benar, pada waktu yang optimal, dan dengan biaya serendah mungkin. UM juga membantu memastikan bahwa perawatan medis efektif, efisien, dan sesuai dengan standar perawatan berbasis bukti. PA adalah alat UM yang memerlukan persetujuan dari perusahaan asuransi sebelum pasien menerima perawatan medis.

Proses UM yang digunakan oleh banyak perusahaan merupakan hambatan untuk memberikan dan menerima perawatan yang tepat waktu. Proses ini mahal, memakan waktu, dan terlalu administratif. Proses ini juga kompleks, manual, dan lambat. Proses ini secara signifikan memengaruhi kemampuan paket kesehatan untuk mengelola kualitas perawatan secara efektif, dan meningkatkan pengalaman penyedia dan anggota. Namun, jika perusahaan ini mengubah proses UM, mereka dapat membantu memastikan bahwa pasien menerima perawatan yang berkualitas tinggi dan hemat biaya. Dengan mengoptimalkan proses UR, paket kesehatan dapat mengurangi biaya dan penolakan melalui pemrosesan permintaan PA yang dipercepat, yang pada akhirnya dapat meningkatkan pengalaman pasien dan penyedia. Pendekatan ini membantu mengurangi beban administrative bagi penyedia layanan kesehatan.

Saat paket kesehatan menerima permintaan PA, pengelola kasus PA akan membuat kasus di sistem pengelolaan kasus untuk melacak, mengelola, dan memproses permintaan. Sebagian besar permintaan ini diterima melalui faks dan surat, dengan dokumen klinik terlampir. Namun, informasi dalam formulir dan dokumen ini tidak mudah diakses oleh perusahaan asuransi kesehatan untuk analisis data dan intelijen bisnis. Proses saat ini untuk memasukkan informasi dari dokumen ini secara manual ke dalam sistem pengelolaan kasus tidak efisien dan memakan waktu serta dapat menyebabkan error.

Dengan mengotomatiskan proses penyerapan data, paket kesehatan dapat mengurangi biaya, error entri data, dan beban administratif bagi staf. Mengekstrak informasi berharga dari formulir dan dokumen klinis memungkinkan perusahaan asuransi kesehatan mempercepat proses UR.

Pertimbangan desain

Bagian ini memberikan panduan untuk membantu Anda menggunakan arsitektur referensi ini guna mengembangkan satu atau beberapa arsitektur yang membantu Anda memenuhi persyaratan khusus untuk keamanan, keandalan, efisiensi operasional, biaya, dan performa.

Keamanan, privasi, dan kepatuhan:

Bagian ini menjelaskan faktor-faktor yang harus Anda pertimbangkan saat menggunakan arsitektur referensi ini untuk membantu mendesain dan membuat arsitektur di Google Cloud yang membantu Anda memenuhi persyaratan keamanan, privasi, dan kepatuhan.

Di Amerika Serikat, Health Insurance Portability and Accountability Act (dikenal sebagai HIPAA, sebagaimana telah diamendemen, termasuk oleh Health Information Technology for Economic and Clinical Health — HITECH — Act) menuntut kepatuhan terhadap Aturan Keamanan, Aturan Privasi, dan Aturan Pemberitahuan Pelanggaran HIPAA. Google Cloud mendukung kepatuhan HIPAA, tetapi pada akhirnya, Anda bertanggung jawab untuk mengevaluasi kepatuhan HIPAA Anda sendiri. Mematuhi HIPAA adalah tanggung jawab bersama antara Anda dan Google. Jika organisasi Anda tunduk pada HIPAA dan Anda ingin menggunakan produk Google Cloud apa pun sehubungan dengan Informasi Kesehatan Terlindungi (PHI), Anda harus meninjau dan menyetujui Perjanjian Rekanan Bisnis (BAA) Google. Produk Google yang tercakup dalam BAA memenuhi persyaratan berdasarkan HIPAA dan sesuai dengan sertifikasi ISO/IEC 27001, 27017, dan 27018 serta laporan SOC 2 kami.

Tidak semua LLM yang dihosting di Model Garden Vertex AI mendukung HIPAA. Mengevaluasi dan menggunakan LLM yang mendukung HIPAA.

Untuk menilai bagaimana produk Google dapat memenuhi kebutuhan kepatuhan HIPAA Anda, Anda dapat mengacu pada laporan audit pihak ketiga di Pusat referensi kepatuhan.

Sebaiknya pelanggan mempertimbangkan hal berikut saat memilih kasus penggunaan AI, dan mendesain dengan mempertimbangkan hal-hal berikut:

  • Privasi data: Platform Google Cloud Vertex AI dan Document AI tidak menggunakan data pelanggan, penggunaan data, konten, atau dokumen untuk meningkatkan atau melatih model dasar. Anda dapat menyesuaikan model dasar dengan data dan dokumen dalam tenant yang aman di Google Cloud.
  • Library klien server Firestore menggunakan Identity and Access Management (IAM) untuk mengelola akses ke database Anda. Untuk mempelajari informasi keamanan dan privasi Firebase, lihat Privasi dan Keamanan di Firebase.
  • Untuk membantu Anda menyimpan data sensitif,image layanan ingestion_service, hitl_app, dan ur_app dapat dienkripsi menggunakan kunci enkripsi yang dikelola pelanggan (CMEK) atau diintegrasikan dengan Secret Manager.
  • Vertex AI menerapkan kontrol keamanan Google Cloud untuk membantu mengamankan model dan data pelatihan Anda. Beberapa kontrol keamanan tidak didukung oleh fitur AI generatif di Vertex AI. Untuk informasi selengkapnya, lihat Kontrol Keamanan untuk Vertex AI dan Kontrol Keamanan untuk AI Generatif.
  • Sebaiknya gunakan IAM untuk menerapkan prinsip hak istimewa terendah dan pemisahan tugas dengan resource cloud. Kontrol ini dapat membatasi akses di tingkat project, folder, atau set data.
  • Cloud Storage otomatis menyimpan data dalam status terenkripsi. Untuk mempelajari lebih lanjut metode tambahan untuk mengenkripsi data, lihat Opsi enkripsi data.

Produk Google mengikuti Prinsip Responsible AI.

Keandalan

Bagian ini menjelaskan faktor desain yang harus Anda pertimbangkan untuk membuat dan mengoperasikan infrastruktur yang andal guna mengotomatiskan pemrosesan permintaan PA.

Document AI form_processors adalah layanan regional. Data disimpan secara sinkron di beberapa zona dalam satu region. Traffic akan otomatis di-load balanced di seluruh zona. Jika pemadaman zona terjadi, data tidak akan hilang1. Jika terjadi pemadaman layanan regional, layanan tidak akan tersedia hingga Google menyelesaikan pemadaman layanan.

Anda dapat membuat bucket Cloud Storage di salah satu dari tiga lokasi: regional, dua region, atau multi-region, menggunakan bucket pa_forms_bkt, training_forms, eval_forms, tuning_dataset, eval_dataset, clinical_docs, atau um_policies. Data yang disimpan di bucket regional direplikasi secara sinkron di beberapa zona dalam satu region. Untuk ketersediaan yang lebih tinggi, Anda dapat menggunakan bucket dual-region atau multi-region, tempat data direplikasi secara asinkron di seluruh region.

Di Firestore, informasi yang diekstrak dari database pa_form_collection dapat berada di beberapa pusat data untuk membantu memastikan skalabilitas dan keandalan global.

Layanan Cloud Run, ingestion_service,hitl_app, dan ur_app, adalah layanan regional. Data disimpan secara sinkron di beberapa zona dalam satu region. Traffic akan otomatis di-load balanced di seluruh zona. Jika pemadaman layanan zona terjadi, tugas Cloud Run akan terus berjalan dan data tidak akan hilang. Jika pemadaman layanan regional terjadi, tugas Cloud Run akan berhenti berjalan hingga Google menyelesaikan pemadaman layanan. Setiap tugas atau tugas Cloud Run mungkin gagal. Untuk menangani kegagalan tersebut, Anda dapat menggunakan percobaan ulang tugas dan checkpoint. Untuk mengetahui informasi selengkapnya, lihat Praktik terbaik percobaan ulang tugas dan checkpoint. Panduan keandalan Cloud Run menjelaskan beberapa praktik terbaik untuk menggunakan Cloud Run.

Vertex AI adalah platform machine learning komprehensif dan mudah digunakan yang menyediakan lingkungan terpadu untuk siklus proses machine learning, mulai dari persiapan data hingga deployment dan pemantauan model.

Pengoptimalan biaya

Bagian ini berisi panduan untuk mengoptimalkan biaya pembuatan dan pengoperasian arsitektur guna mengotomatiskan pemrosesan permintaan PA dan meningkatkan proses UR Anda. Mengelola penggunaan resource dengan cermat dan memilih tingkat layanan yang sesuai dapat berdampak signifikan pada biaya keseluruhan.

Kelas penyimpanan Cloud Storage: Gunakan berbagai kelas penyimpanan (Standard, Nearline, Coldline, atau Archive) berdasarkan frekuensi akses data. Nearline, Coldline, dan Archive lebih hemat biaya untuk data yang jarang diakses.

Kebijakan siklus proses Cloud Storage: Terapkan kebijakan siklus proses untuk mentransisikan objek secara otomatis ke kelas penyimpanan berbiaya lebih rendah atau menghapusnya berdasarkan usia dan pola akses.

Document AI dihargai berdasarkan jumlah prosesor yang di-deploy dan berdasarkan jumlah halaman yang diproses oleh prosesor Document AI. Pertimbangkan hal berikut:

  • Pengoptimalan prosesor: Menganalisis pola beban kerja untuk menentukan jumlah pemroses Document AI yang optimal untuk di-deploy. Hindari overprovisioning resource.
  • Pengelolaan volume halaman: Memproses dokumen terlebih dahulu untuk menghapus halaman yang tidak diperlukan atau mengoptimalkan resolusi dapat membantu mengurangi biaya pemrosesan.

Firestore dihargai berdasarkan aktivitas yang terkait dengan dokumen, entri indeks, penyimpanan yang digunakan database, dan jumlah bandwidth jaringan. Pertimbangkan hal berikut:

  • Pemodelan data: Desain model data Anda untuk meminimalkan jumlah entri indeks dan mengoptimalkan pola kueri untuk efisiensi.
  • Bandwidth jaringan: Pantau dan optimalkan penggunaan jaringan untuk menghindari tagihan berlebih. Pertimbangkan untuk menyimpan cache data yang sering diakses.

Biaya Cloud Run dihitung berdasarkan penggunaan CPU, memori, dan jumlah permintaan on-demand. Pertimbangkan alokasi resource dengan cermat. Mengalokasikan resource CPU dan memori berdasarkan karakteristik beban kerja. Gunakan penskalaan otomatis untuk menyesuaikan resource secara dinamis berdasarkan permintaan.

LLM Vertex AI biasanya dikenai biaya berdasarkan input dan output teks atau media. Jumlah token input dan output secara langsung memengaruhi biaya LLM. Optimalkan perintah dan pembuatan respons untuk efisiensi.

Biaya mesin penelusuran Vertex AI Agent Builder bergantung pada fitur yang Anda gunakan. Untuk membantu mengelola biaya, Anda dapat memilih dari tiga opsi berikut:

  • Search Standard Edition, yang menawarkan kemampuan penelusuran tidak terstruktur.
  • Search Enterprise Edition, yang menawarkan kemampuan penelusuran tidak terstruktur dan penelusuran situs.
  • Add-On LLM Penelusuran, yang menawarkan kemampuan ringkasan dan penelusuran multi-giliran.

Anda juga dapat mempertimbangkan pertimbangan tambahan berikut untuk membantu mengoptimalkan biaya:

  • Pemantauan dan pemberitahuan: Siapkan Cloud Monitoring dan pemberitahuan penagihan untuk melacak biaya dan menerima notifikasi saat penggunaan melebihi nilai minimum.
  • Laporan biaya: Tinjau laporan biaya secara rutin di konsol Google Cloud untuk mengidentifikasi tren dan mengoptimalkan penggunaan resource.
  • Pertimbangkan diskon abonemen: Jika Anda memiliki beban kerja yang dapat diprediksi, pertimbangkan untuk berkomitmen menggunakan resource tersebut selama jangka waktu tertentu untuk mendapatkan harga diskon.

Dengan mempertimbangkan faktor-faktor ini dengan cermat dan menerapkan strategi yang direkomendasikan, Anda dapat mengelola dan mengoptimalkan biaya menjalankan arsitektur otomatisasi UR dan PA di Google Cloud secara efektif.

Deployment

Kode implementasi referensi untuk arsitektur ini tersedia berdasarkan lisensi open source. Arsitektur yang diterapkan kode ini adalah prototipe, dan mungkin tidak menyertakan semua fitur dan hardening yang Anda perlukan untuk deployment produksi. Untuk menerapkan dan memperluas arsitektur referensi ini agar lebih sesuai dengan persyaratan Anda, sebaiknya hubungi Konsultasi Google Cloud.

Kode awal untuk arsitektur referensi ini tersedia di repositori git berikut:

Anda dapat memilih salah satu dari dua opsi berikut untuk menerapkan dukungan dan layanan untuk arsitektur referensi ini:

Langkah selanjutnya

Kontributor

Penulis: Dharmesh Patel | Industry Solutions Architect, Healthcare

Kontributor lainnya:

  1. Region Meksiko, Montreal, dan Osaka memiliki tiga zona dalam satu atau dua pusat data fisik. Region ini sedang dalam proses perluasan ke minimal tiga pusat data fisik. Untuk mengetahui informasi selengkapnya, lihat Lokasi Cloud dan SLA Google Cloud Platform. Untuk membantu meningkatkan keandalan workload Anda, pertimbangkan deployment multi-regional.  ↩