This page explains when to choose the
method for importing FHIR resources to the Cloud Healthcare API from
method is primarily intended to load data into an empty FHIR store without other
applications accessing the store during import. It's optimized to load large
quantities of data using import semantics that ignore some FHIR store
configuration options, as described in this section. For information about using
Importing and exporting FHIR resources using Cloud Storage.
Consider the following characteristics of the
method when deciding whether to use it. If
fhirStores.import isn't suitable
for your application, consider using the
method to load data. For information about
Managing FHIR resources using FHIR bundles.
- Each resource in the input must contain a client-supplied ID. Each resource is
stored using the provided ID regardless of the
enableUpdateCreatesetting on the FHIR store.
- The import process doesn't enforce referential integrity, regardless of the
disableReferentialIntegritysetting on the FHIR store. Not enforcing referential integrity lets you import resources with arbitrary interdependencies without considering grouping or ordering. If the input data contains invalid references or if some resources fail to import, the state of the FHIR store might violate referential integrity.
- If a resource with a given ID already exists in the store, the most recent
version of the resource is overwritten without creating a new historical
version. The overwriting occurs regardless of the
disableResourceVersioningsetting on the FHIR store. If transient failures occur during the import, a successfully imported resource could be overwritten more than once.
- The import operation is idempotent unless the input data contains multiple valid resources with the same ID but different contents. In that case, after the import completes, the store contains exactly one resource with each ID, but the duplicate entries could contain any version of the contents. For example, importing a million resources with the same ID writes only one resource to the store.
- The operation result counters don't count duplicate IDs as an error. Each
resource in the input counts as one success. This could result
in a success count larger than the number of resources in the FHIR store. This
often occurs when importing data organized in bundles produced by
Patient-everythingwhere each bundle contains its own copy of a resource, such as
Practitioner, that might be referenced by many patients.
- If some resources fail to import, such as due to parsing errors, successfully imported resources aren't rolled back. For example, if 5 of 100 resources fail to import, the remaining 95 resources are imported into the store.
- When using the
BUNDLEformat, the import method rejects bundles with
history. The import method doesn't apply the bundle processing semantics for batch or transaction bundles. Unlike in
fhir.executeBundle, transaction bundles aren't executed as a single transaction and bundle-internal references aren't rewritten. The bundle is treated as a collection of resources to be written as provided in
Bundle.entry.request. For example, this allows the import of searchset bundles produced by a FHIR search or