FHIR import

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 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 BUNDLE format, the import method rejects bundles with Bundle.type of 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.resource, ignoring Bundle.entry.request. For example, this allows the import of searchset bundles produced by a FHIR search or Patient-everything operation.