This page explains when to choose the
fhirStores.import
method for importing FHIR resources to the Cloud Healthcare API from
Cloud Storage.
fhirStores.import
method
The
fhirStores.import
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 fhirStores.import
, see
Importing and exporting FHIR resources using Cloud Storage.
Consider the following characteristics of the fhirStores.import
method when deciding whether to use it. If fhirStores.import
isn't suitable
for your application, consider using the
fhir.executeBundle
method to load data. For information about fhir.executeBundle
, see
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
enableUpdateCreate
setting on the FHIR store. - The import process doesn't enforce referential integrity, regardless of the
disableReferentialIntegrity
setting 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
disableResourceVersioning
setting 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-everything
where each bundle contains its own copy of a resource, such asPractitioner
, 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
BUNDLE
format, the import method rejects bundles withBundle.type
ofhistory
. The import method doesn't apply the bundle processing semantics for batch or transaction bundles. Unlike infhir.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 inBundle.entry.resource
, ignoringBundle.entry.request
. For example, this allows the import of searchset bundles produced by a FHIR search orPatient-everything
operation.