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 persetujuan awal (PA) dan meningkatkan proses peninjauan pemanfaatan (UR) mereka menggunakan Google Cloud. Dokumen ini ditujukan untuk developer software dan administrator program di organisasi ini. Arsitektur ini membantu penyedia rencana kesehatan mengurangi biaya administrasi, meningkatkan efisiensi, dan meningkatkan pengambilan keputusan dengan mengotomatiskan penyerapan data dan ekstraksi insight dari formulir klinis. Selain itu, pengguna dapat menggunakan model AI untuk membuat 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:

  • Pengaktif data klaim (CDA), yang mengekstrak data dari sumber tidak terstruktur, seperti formulir dan dokumen, lalu memasukkannya ke dalam database dalam format terstruktur yang dapat dibaca mesin. CDA menerapkan alur data untuk menyerap formulir permintaan PA.
  • Layanan tinjauan pemanfaatan (layanan UR), yang mengintegrasikan data permintaan PA, dokumen kebijakan, dan pedoman perawatan lainnya untuk membuat rekomendasi. Layanan UR menerapkan alur data untuk meninjau permintaan PA menggunakan AI generatif.

Bagian berikut menjelaskan alur data ini.

Alur data CDA

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

Alur 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 perubahan di bucket pa_forms_bkt. Layanan ingestion_service mengambil formulir pa_forms dari bucket pa_forms_bkt. Layanan mengidentifikasi pemroses Document 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 form_processors pemroses. 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 di output oleh model machine learning (ML) form_processors.
  5. Aplikasi hitl_app menampilkan informasi yang diekstrak dengan skor keyakinan tingkat dokumen dan bidang kepada pengelola kasus PA sehingga mereka dapat meninjau dan mengoreksi informasi tersebut jika nilai yang diekstrak tidak akurat. Pengelola kasus PA dapat memperbarui nilai yang salah dan menyimpan dokumen di database pa_form_collection.

Alur 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 terhadap permintaan PA. Spesialis UR biasanya adalah perawat atau dokter yang berpengalaman di bidang klinis tertentu dan bekerja di perusahaan asuransi kesehatan. Alur kerja pengelolaan kasus dan perutean 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. Aplikasi ini menggunakan Vertex AI Gemini API untuk membuat perintah yang mirip dengan berikut ini:

     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 dibuat kepada spesialis UR untuk ditinjau dan diberi masukan. Spesialis UR dapat memperbarui perintah di UI dan mengirimkannya 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 untuk 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 penyesuaian model bahasa besar (LLM).
    • eval_dataset: Bucket untuk menyimpan data yang diperlukan untuk evaluasi LLM.
    • clinical_docs: Bucket untuk menyimpan dokumen klinis yang dikirimkan penyedia layanan kesehatan sebagai lampiran pada formulir PA atau setelahnya untuk mendukung kasus PA. Dokumen ini diindeks oleh aplikasi penelusuran di layanan Aplikasi AI.
    • um_policies: Bucket untuk menyimpan pedoman kebutuhan dan perawatan medis, dokumen kebijakan rencana kesehatan, dan pedoman cakupan. Dokumen ini diindeks oleh aplikasi penelusuran di layanan Aplikasi AI.

  • 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 diuraikan, 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. Sistem ini juga merender skor keyakinan yang dilaporkan oleh pemroses formulir (model ML) kepada pengelola kasus PA agar mereka dapat meninjau, mengoreksi, dan menyimpan informasi di datastore.

  • ur_app: Microservice (aplikasi web) yang dapat digunakan oleh 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 diteruskan ke model ur_model untuk mendapatkan rekomendasi kasus.

  • LLM yang disesuaikan untuk medis di Vertex AI: 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 pada LLM yang disesuaikan untuk membuat perintah berdasarkan data yang diekstrak dari pa_forms.
    • ur_model: Adaptor pada LLM yang disesuaikan untuk membuat draf rekomendasi berdasarkan perintah input.

  • ur_search_app: Aplikasi penelusuran yang dibuat dengan Aplikasi AI 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 AI.
  • Aplikasi AI: Platform yang memungkinkan developer membuat dan men-deploy agen dan aplikasi berteknologi AI tingkat 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 bersifat skalabel.
  • Cloud Storage: Penyimpanan objek berbiaya rendah dan tanpa batas untuk beragam jenis data. Data dapat diakses dari dalam dan luar Google Cloud, serta direplikasi di berbagai 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 kesehatan. Tujuan UM adalah membantu memastikan bahwa pasien menerima perawatan yang tepat dalam lingkungan 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 banyak perusahaan menjadi penghalang untuk memberikan dan menerima perawatan tepat waktu. Proses ini mahal, memakan waktu, dan terlalu administratif. Proses ini juga rumit, manual, dan lambat. Proses ini secara signifikan memengaruhi kemampuan rencana kesehatan untuk mengelola kualitas perawatan secara efektif, serta meningkatkan pengalaman penyedia layanan dan anggota. Namun, jika perusahaan ini memodifikasi proses UM mereka, mereka dapat membantu memastikan bahwa pasien menerima perawatan berkualitas tinggi dan hemat biaya. Dengan mengoptimalkan proses UR, rencana kesehatan dapat mengurangi biaya dan penolakan melalui pemrosesan permintaan PA yang dipercepat, yang pada gilirannya dapat meningkatkan pengalaman pasien dan penyedia. Pendekatan ini membantu mengurangi beban administratif pada penyedia layanan kesehatan.

Saat menerima permintaan untuk PA, pengelola kasus PA membuat kasus dalam sistem pengelolaan kasus untuk melacak, mengelola, dan memproses permintaan tersebut. Sebagian besar permintaan ini diterima melalui faks dan surat, dengan dokumen klinis 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-dokumen ini ke dalam sistem pengelolaan kasus secara manual tidak efisien dan memakan waktu serta dapat menyebabkan error.

Dengan mengotomatiskan proses penyerapan data, rencana kesehatan dapat mengurangi biaya, kesalahan entri data, dan beban administratif pada 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 spesifik dalam hal 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 merancang dan membangun arsitektur diGoogle 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 terhadap 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 apa pun yang terkait dengan Informasi Kesehatan Terlindungi (PHI), Anda harus meninjau dan menyetujui Perjanjian Rekanan Bisnis (BAA) Google. Google CloudProduk Google yang dicakup oleh BAA memenuhi persyaratan yang ada dalam HIPAA dan selaras dengan sertifikasi ISO/IEC 27001, 27017, dan 27018 serta laporan SOC 2 kami.

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

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

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

  • Privasi data: Platform Vertex AI dan Document AI tidak menggunakan data pelanggan, penggunaan data, konten, atau dokumen untuk meningkatkan kualitas atau melatih model dasar. Google Cloud Anda dapat menyesuaikan model dasar dengan data dan dokumen Anda dalam tenant yang diamankan 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,gambar 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 Google Cloud kontrol keamanan untuk membantu mengamankan model dan data pelatihan Anda. Beberapa kontrol keamanan tidak didukung oleh fitur AI generatif di Vertex AI. Untuk mengetahui informasi selengkapnya, lihat Kontrol Keamanan untuk Vertex AI dan Kontrol Keamanan untuk AI Generatif.
  • Sebaiknya Anda menggunakan 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 keadaan terenkripsi. Untuk mempelajari lebih lanjut metode tambahan untuk mengenkripsi data, lihat Opsi enkripsi data.

Produk Google mematuhi prinsip Responsible AI.

Untuk mengetahui prinsip dan rekomendasi keamanan yang khusus untuk workload AI dan ML, lihat Perspektif AI dan ML: Keamanan dalam Framework yang Dirancang dengan Baik.

Keandalan

Bagian ini menjelaskan faktor desain yang harus Anda pertimbangkan untuk membangun 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 terjadi pemadaman zona, data tidak akan hilang1. Jika terjadi pemadaman layanan regional, layanan tidak akan tersedia hingga Google menyelesaikan pemadaman layanan tersebut.

Anda dapat membuat bucket Cloud Storage di salah satu dari tiga lokasi: regional, dual-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 terjadi pemadaman zona, tugas Cloud Run akan terus berjalan dan data tidak akan hilang. Jika terjadi pemadaman layanan di suatu region, tugas Cloud Run akan berhenti berjalan hingga Google menyelesaikan pemadaman layanan tersebut. Setiap tugas atau task Cloud Run dapat gagal. Untuk menangani kegagalan tersebut, Anda dapat menggunakan coba lagi tugas dan checkpoint. Untuk mengetahui informasi selengkapnya, lihat Praktik terbaik percobaan ulang tugas dan checkpoint. Tips pengembangan umum Cloud Run menjelaskan beberapa praktik terbaik untuk menggunakan Cloud Run.

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

Untuk prinsip dan rekomendasi keandalan yang khusus untuk workload AI dan ML, lihat Perspektif AI dan ML: Keandalan dalam Well-Architected Framework.

Pengoptimalan biaya

Bagian ini memberikan panduan untuk mengoptimalkan biaya pembuatan dan menjalankan arsitektur untuk 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 lebih jarang diakses.

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

Document AI dikenai biaya berdasarkan jumlah pemroses yang di-deploy dan berdasarkan jumlah halaman yang diproses oleh pemroses Document AI. Pertimbangkan hal berikut:

  • Pengoptimalan pemroses: Analisis pola workload untuk menentukan jumlah pemroses Document AI yang optimal untuk di-deploy. Hindari penyediaan resource yang berlebihan.
  • Pengelolaan volume halaman: Memproses dokumen terlebih dahulu untuk menghapus halaman yang tidak perlu atau mengoptimalkan resolusi dapat membantu mengurangi biaya pemrosesan.

Firestore dikenai biaya 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 agar efisien.
  • Bandwidth jaringan: Pantau dan optimalkan penggunaan jaringan untuk menghindari biaya yang berlebihan. Pertimbangkan untuk melakukan caching data yang sering diakses.

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

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

Biaya mesin telusur Aplikasi AI 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 konsolGoogle 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 secara cermat dan menerapkan strategi yang direkomendasikan, Anda dapat mengelola dan mengoptimalkan biaya menjalankan arsitektur otomatisasi PA dan UR secara efektif di Google Cloud.

Untuk prinsip dan rekomendasi pengoptimalan biaya yang khusus untuk workload AI dan ML, lihat Perspektif AI dan ML: Pengoptimalan biaya dalam Framework yang Dirancang dengan Baik.

Deployment

Kode implementasi referensi untuk arsitektur ini tersedia dengan lisensi open source. Arsitektur yang diimplementasikan oleh kode ini adalah prototipe, dan mungkin tidak menyertakan semua fitur dan penguatan 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 berikutnya

Kontributor

Penulis: Dharmesh Patel | Industry Solutions Architect, Healthcare

Kontributor lainnya:

  1. Untuk mengetahui informasi selengkapnya tentang pertimbangan khusus wilayah, lihat Geografi dan wilayah.  ↩