Halaman ini menjelaskan opsi untuk menyimpan batch besar data FHIR di Cloud Healthcare API.
Mengimpor resource FHIR
Gunakan metode fhirStores.import
untuk memuat resource FHIR dari Cloud Storage ke Cloud Healthcare API.
Metode ini berperforma terbaik saat memuat data ke penyimpanan FHIR kosong tanpa gangguan
dari aplikasi lain.
Untuk memanggil fhirStores.import
, lihat
Mengimpor dan mengekspor resource FHIR menggunakan Cloud Storage.
Pertimbangkan properti metode fhirStores.import
berikut saat memutuskan apakah akan menggunakannya. Jika fhirStores.import
tidak cocok
untuk aplikasi Anda, pertimbangkan untuk menggunakan
metode
fhir.executeBundle
untuk memuat data. Untuk informasi tentang cara memanggil fhir.executeBundle
, lihat
Mengelola resource FHIR menggunakan paket FHIR.
- Metode
fhirStores.import
menerima paket yang lebih besar dari batas 50 MB difhir.executeBundle
. Namun, ukuran setiap resource dalam paket dibatasi hingga 10 MB. Penggunaan
fhirStores.import
menghilangkan kompleksitas dalam menjalankan paket FHIR besar, seperti berikut:- Memecah paket FHIR menjadi paket yang lebih kecil
- Mengelola beberapa jadwal paket
- Mengelola error sementara yang dapat dicoba lagi di tingkat resource atau paket
Sering kali, keuntungan ini lebih besar daripada keuntungan menggunakan paket.
Setiap resource dalam input harus berisi ID yang disediakan klien. Setiap resource disimpan menggunakan ID yang diberikan, terlepas dari setelan
enableUpdateCreate
di penyimpanan FHIR.Proses impor tidak menerapkan integritas referensial, terlepas dari setelan
disableReferentialIntegrity
di penyimpanan FHIR. Tidak menerapkan integritas referensial memungkinkan Anda mengimpor resource dengan dependensi arbitrer tanpa mempertimbangkan pengelompokan atau pengurutan. Jika data input berisi referensi yang tidak valid atau jika beberapa resource gagal diimpor, status penyimpanan FHIR mungkin melanggar integritas referensi.Jika resource dengan ID tertentu sudah ada di penyimpanan, versi terbaru resource akan ditimpa tanpa membuat versi historis baru. Penggantian terjadi terlepas dari setelan
disableResourceVersioning
di penyimpanan FHIR. Jika kegagalan sementara terjadi selama impor, resource yang berhasil diimpor dapat ditimpa lebih dari sekali.Operasi impor bersifat idempoten kecuali jika data input berisi beberapa resource yang valid dengan ID yang sama, tetapi kontennya berbeda. Dalam hal ini, setelah impor selesai, penyimpanan akan berisi tepat satu resource dengan setiap ID, tetapi entri duplikat dapat berisi versi konten apa pun. Misalnya, mengimpor satu juta resource dengan ID yang sama hanya akan menulis satu resource ke penyimpanan.
Penghitung hasil operasi tidak menghitung ID duplikat sebagai error. Setiap resource dalam input dihitung sebagai satu keberhasilan. Hal ini dapat mengakibatkan jumlah keberhasilan yang lebih besar daripada jumlah resource di penyimpanan FHIR. Hal ini sering terjadi saat mengimpor data yang diatur dalam paket yang dihasilkan oleh
Patient-everything
, dengan setiap paket berisi salinan resource-nya sendiri, sepertiPractitioner
, yang mungkin direferensikan oleh banyak resource Pasien.Jika beberapa resource gagal diimpor, seperti karena error penguraian, resource yang berhasil diimpor tidak akan di-roll back. Misalnya, jika 5 dari 100 resource gagal diimpor, 95 resource lainnya akan diimpor ke penyimpanan FHIR.
Saat menggunakan format
BUNDLE
, metode impor akan menolak paket denganBundle.type
darihistory
. Metode impor tidak menerapkan semantik pemrosesan paket untuk paket batch atau transaksi. Tidak seperti difhir.executeBundle
, paket transaksi tidak dijalankan sebagai satu transaksi dan referensi internal paket tidak ditulis ulang. Paket diperlakukan sebagai kumpulan resource yang akan ditulis seperti yang disediakan diBundle.entry.resource
, dengan mengabaikanBundle.entry.request
. Misalnya, hal ini memungkinkan impor paket set penelusuran yang dihasilkan oleh penelusuran FHIR atau operasiPatient-everything
.
Menggunakan paket FHIR
Lihat Paket FHIR untuk ringkasan paket FHIR.
Kapan harus menggunakan paket FHIR
Pertimbangkan karakteristik dan keuntungan berikut dari penggunaan metode fhir.executeBundle
saat memutuskan apakah akan menggunakannya untuk menyimpan resource FHIR:
- Jika terlalu mahal, baik dalam hal biaya penagihan maupun bandwidth jaringan, untuk membuat pipeline yang menyimpan data di Cloud Storage, lalu mengimpor data menggunakan
fhirStores.import
, gunakanfhir.executeBundle
. - Saat menjalankan paket, integritas transaksi dapat diterapkan.
- Saat menjalankan paket, validasi profil FHIR dapat diterapkan.
- Jika Anda perlu mengirim notifikasi Pub/Sub saat operasi pembuatan, pembaruan, atau penghapusan FHIR terjadi, gunakan
fhir.executeBundle
. Notifikasi Pub/Sub tidak dikirim saat resource FHIR diimpor menggunakanfhirStores.import
. - Jika waktu saat resource FHIR tertentu harus diproses dalam
detik atau menit, gunakan
fhir.executeBundle
. Jika waktu saat resource FHIR tertentu harus diproses adalah dalam jam atau hari, gunakanfhirStores.import
. - Jika project Google Cloud Anda memiliki banyak operasi yang berjalan lama (LRO) yang ada
yang melakukan tugas lain, Anda mungkin melihat performa yang lebih baik
dengan
fhir.executeBundle
dibandingkanfhirStores.import
. Jika aplikasi yang mengelola operasi
fhirStores.import
tidak memiliki strategi yang baik untuk hal berikut, gunakanfhir.executeBundle
:- Menangani error massal
- Mengatasi kegagalan pada sebagian resource FHIR atau seluruh batch
Kapan sebaiknya paket FHIR tidak digunakan
Pertimbangkan batasan fhir.executeBundle
berikut saat menentukan
apakah akan menggunakannya untuk menyimpan resource FHIR:
Paket memiliki kuota dan penagihan yang setara yang diterapkan ke operasi di dalam paket seolah-olah operasi dieksekusi di luar paket. Misalnya, jika paket memiliki 10 operasi
POST
, 5 operasiGET
, dan 1 operasiDELETE
, kuota dan penagihan yang diterapkan ke paket sama seperti jika operasi tersebut dijalankan secara independen.Akibatnya, menurunkan batas kuota dan biaya operasi FHIR bukanlah alasan untuk menggunakan paket, bukan
fhirStores.import
.Paket transaksi besar mungkin lebih cenderung memiliki konflik transaksi yang menyebabkan pertentangan data dan operasi yang gagal. Untuk mengetahui informasi tentang cara terjadinya masalah ini, dan cara mengatasinya, lihat Mencegah error
429 Resource Exhausted operation_too_costly
.Anda dapat mencapai dan mempertahankan throughput data yang tinggi menggunakan paket batch, yang membantu Anda menghindari pertentangan data. Namun, paket batch tidak memiliki kemampuan konsistensi transaksional, seperti integritas referensial
Jika paket berukuran besar, meskipun merupakan paket batch, Anda mungkin melihat throughput data yang menurun. Untuk informasi selengkapnya, lihat Menghindari paket transaksi besar.