Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
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.
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 di fhir.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 ulang 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,
seperti Practitioner, 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 dengan
Bundle.type dari history. Metode impor tidak menerapkan semantik pemrosesan
paket untuk paket batch atau transaksi.
Tidak seperti di fhir.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 di
Bundle.entry.resource, dengan mengabaikan Bundle.entry.request. Misalnya, hal ini
memungkinkan impor paket set penelusuran yang dihasilkan oleh penelusuran FHIR atau
operasi Patient-everything.
Pertimbangkan karakteristik dan keunggulan 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, gunakan fhir.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 menggunakan fhirStores.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, gunakan
fhirStores.import.
Jika Google Cloud project Anda memiliki banyak operasi yang berjalan lama (LRO) yang ada
yang melakukan tugas lain, Anda mungkin melihat performa yang lebih baik
dengan fhir.executeBundle dibandingkan fhirStores.import.
Jika aplikasi yang mengelola operasi fhirStores.import tidak
memiliki strategi yang baik untuk hal berikut, gunakan fhir.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 operasi GET, dan 1 operasi DELETE,
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.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-03 UTC."],[[["\u003cp\u003eThis page outlines two primary methods for storing large amounts of FHIR data in the Cloud Healthcare API: using \u003ccode\u003efhirStores.import\u003c/code\u003e or \u003ccode\u003efhir.executeBundle\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003efhirStores.import\u003c/code\u003e method is ideal for loading data from Cloud Storage into an empty FHIR store, accepting bundles larger than 50MB but with individual resource size limits of 10MB.\u003c/p\u003e\n"],["\u003cp\u003eUsing \u003ccode\u003efhirStores.import\u003c/code\u003e simplifies managing large FHIR data sets by removing the need to break down bundles, manage schedules, and handle transient errors, however, it does not enforce referential integrity or resource versioning.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003efhir.executeBundle\u003c/code\u003e method is best when real-time processing of resources is necessary, such as when Pub/Sub notifications or FHIR profile validation is needed, and is preferable for applications with many long-running operations.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003efhir.executeBundle\u003c/code\u003e provides transactional integrity, but batch bundles lack transactional consistency, and large bundles may have data contention, impacting data throughput.\u003c/p\u003e\n"]]],[],null,["# FHIR import options\n\nThis page describes options for storing large batches of FHIR data in the\nCloud Healthcare API.\n| **Tip:** If you're importing data from an external bulk FHIR server, consider using the Google open source [Bulk FHIR Tools](https://github.com/google/bulk_fhir_tools) to load data directly into the Cloud Healthcare API.\n\nImport FHIR resources\n---------------------\n\nUse the\n[`fhirStores.import`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.fhirStores/import)\nmethod to load FHIR resources from Cloud Storage into the Cloud Healthcare API.\nThe method performs best when loading data into an empty FHIR store without interference\nfrom other applications.\n\nTo call `fhirStores.import`, see\n[Importing and exporting FHIR resources using Cloud Storage](/healthcare-api/docs/how-tos/fhir-import-export).\n\nConsider the following properties of `fhirStores.import`\nmethod when deciding whether to use it. If `fhirStores.import` isn't suitable\nfor your application, consider using the\n[`fhir.executeBundle`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.fhirStores.fhir/executeBundle)\nmethod to load data. For information about how to call `fhir.executeBundle`, see\n[Managing FHIR resources using FHIR bundles](/healthcare-api/docs/how-tos/fhir-bundles).\n\n- The `fhirStores.import` method accepts bundles larger than the [50 MB limit](/healthcare-api/quotas#resource_limits) on `fhir.executeBundle`. However, the size of each individual resource within the bundle is limited to [10 MB](/healthcare-api/quotas#resource_limits).\n- Using `fhirStores.import` removes the complexities of executing\n large FHIR bundles, such as the following:\n\n - Breaking up FHIR bundles into smaller bundles\n - Managing multiple bundle schedules\n - Managing transient errors that can be retried at the resource or bundle level\n\n Often, these advantages outweigh the advantages from using bundles.\n- Each resource in the input must contain a client-supplied ID. Each resource is\n stored using the provided ID regardless of the\n [`enableUpdateCreate`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.fhirStores#FhirStore.FIELDS.enable_update_create)\n setting on the FHIR store.\n\n- The import process doesn't enforce referential integrity, regardless of the\n [`disableReferentialIntegrity`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.fhirStores#FhirStore.FIELDS.disable_referential_integrity)\n setting on the FHIR store. Not enforcing referential integrity lets you\n import resources with arbitrary interdependencies without considering grouping\n or ordering. If the input data contains invalid references or if some\n resources fail to import, the state of the FHIR store might violate\n referential integrity.\n\n- If a resource with a given ID already exists in the store, the most recent\n version of the resource is overwritten without creating a new historical\n version. The overwriting occurs regardless of the\n [`disableResourceVersioning`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.fhirStores#FhirStore.FIELDS.disable_resource_versioning)\n setting on the FHIR store. If transient failures occur during the import, a\n successfully imported resource could be overwritten more than once.\n\n- The import operation is idempotent unless the input data contains multiple\n valid resources with the same ID but different contents. In that case, after\n the import completes, the store contains exactly one resource with each ID,\n but the duplicate entries could contain any version of the contents. For\n example, importing a million resources with the same ID writes only one\n resource to the store.\n\n- The operation result counters don't count duplicate IDs as an error. Each\n resource in the input counts as one success. This could result\n in a success count larger than the number of resources in the FHIR store. This\n often occurs when importing data organized in bundles produced by\n `Patient-everything` where each bundle contains its own copy of a resource,\n such as `Practitioner`, that might be referenced by many Patient resources.\n\n- If some resources fail to import, such as due to parsing errors,\n successfully imported resources aren't rolled back. For example, if 5 of 100\n resources fail to import, the remaining 95 resources are imported into the\n FHIR store.\n\n- When using the `BUNDLE` format, the import method rejects bundles with\n `Bundle.type` of `history`. The import method doesn't apply the bundle\n processing semantics for batch or transaction bundles.\n Unlike in `fhir.executeBundle`, transaction bundles aren't executed as a\n single transaction and bundle-internal references aren't rewritten. The\n bundle is treated as a collection of resources to be written as provided in\n `Bundle.entry.resource`, ignoring `Bundle.entry.request`. For example, this\n allows the import of searchset bundles produced by a FHIR search or\n `Patient-everything` operation.\n\nUse FHIR bundles\n----------------\n\nSee [FHIR bundles](/healthcare-api/docs/how-tos/fhir-bundles#fhir_bundles) for\nan overview of FHIR bundles.\n\n### When to use FHIR bundles\n\nConsider the following characteristics and advantages of using the `fhir.executeBundle`\nmethod when deciding whether to use it to store FHIR resources:\n\n- If it is too costly, either in terms of billing costs or network bandwidth, to build a pipeline that stores data in Cloud Storage and then imports the data using `fhirStores.import`, use `fhir.executeBundle`.\n- When executing bundles, transaction integrity can be enforced.\n- When executing bundles, FHIR profile validation can be enforced.\n- If you need to send [Pub/Sub notifications](/healthcare-api/docs/how-tos/pubsub) when FHIR create, update, or delete operations occur, use `fhir.executeBundle`. Pub/Sub notifications are not sent when FHIR resources are imported using `fhirStores.import`.\n- If the time at which a particular FHIR resource must be processed is in in seconds or minutes, use `fhir.executeBundle`. If the time at which a particular FHIR resource must be processed is in hours or days, use `fhirStores.import`.\n- If your Google Cloud project has many existing long-running operations (LRO) performing other tasks, you might see better performance with `fhir.executeBundle` over `fhirStores.import`.\n- If the application managing the `fhirStores.import` operation doesn't\n have a good strategy for the following, use `fhir.executeBundle`:\n\n - Handling bulk errors\n - Addressing failures on a subset of FHIR resources or entire batches\n\n### When not to use FHIR bundles\n\nConsider the following limitations of `fhir.executeBundle` when determining\nwhether to use it to store FHIR resources:\n\n- Bundles have the equivalent quota and billing applied to the operations inside\n the bundle as if the operations were executed outside of the bundle. For example,\n if a bundle has 10 `POST` operations, 5 `GET` operations, and 1 `DELETE` operation,\n the quota and billing applied to the bundle is the same as if those operations\n were executed independently.\n\n As a result, aiming to lower quota limits and FHIR operation costs are not reasons to use\n bundles instead of `fhirStores.import`.\n- Large transaction bundles might be more likely to have transaction conflicts\n which leads to data contention and failed operations. For information on\n how these issues can occur, and how to resolve them, see [Prevent `429 Resource Exhausted operation_too_costly` errors](/healthcare-api/docs/best-practices-data-throughput#prevent-429).\n\n- You can achieve and maintain high data throughput using batch bundles, which\n helps you to avoid data contention. However, batch bundles do not\n have transactional consistency\n capabilities, such as [referential integrity](/healthcare-api/docs/concepts/fhir-referential-integrity)\n\n- If a bundle is large, even if it's a batch bundle, you might see reduced\n data throughput. For more information, see [Avoid large transaction bundles](/healthcare-api/docs/best-practices-data-throughput#avoid-large)."]]
