[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-18。"],[[["\u003cp\u003eGoogle Cloud Healthcare API data is stored in either a regional location, which is a specific geographic place, or a multi-regional location, a large geographic area with at least two regional locations.\u003c/p\u003e\n"],["\u003cp\u003eWhen creating a dataset in the Cloud Healthcare API, you must specify a location, which becomes a permanent part of the dataset's identity and cannot be changed after creation.\u003c/p\u003e\n"],["\u003cp\u003eThe Cloud Healthcare API supports a subset of Google Cloud locations, and there are numerous options within Americas, Asia Pacific, Europe, and Middle East regional locations, along with 'us' and 'eu' as multi-regional locations.\u003c/p\u003e\n"],["\u003cp\u003eMoving Cloud Healthcare API data between locations requires exporting the data to Cloud Storage and then importing it into a newly created dataset and corresponding stores in the desired location.\u003c/p\u003e\n"],["\u003cp\u003eFactors such as regulatory requirements, latency, resiliency, cost, and colocation with other Google Cloud services should be considered when choosing a location for your Cloud Healthcare API data.\u003c/p\u003e\n"]]],[],null,["# Regions\n\nGoogle Cloud uses [regions, subdivided into zones](/docs/geography-and-regions#regions_and_zones),\nto define the geographic location of physical computing resources.\n\nKey concepts\n------------\n\nYou specify a location for storing your Cloud Healthcare API data when\nyou create a dataset. After you create the dataset, the location cannot be\nchanged. Data within the dataset is stored at rest in the chosen location.\n\nThe location is tied to the dataset's identity and is a permanent part of the\ndataset's [resource name](/healthcare-api/docs/concepts/api-structure#resource_names).\nAll data stores within the dataset are assigned to the same region as the\ndataset.\n\nThere are two types of locations:\n\n- A *regional location* is a specific geographic place, such as Tokyo.\n For more information, see [Regional resources](/docs/geography-and-regions#regional_resources)\n on the Geography and Regions page.\n\n- A *multi-regional location* is a large geographic area, such as the United\n States, that contains at least two regional locations. For more information,\n see [Multi-regional resources](/docs/geography-and-regions#multiregional_resources)\n on the Geography and Regions page.\n\nAvailable regions\n-----------------\n\nThe Cloud Healthcare API supports a subset of the\n[full list of Google Cloud locations](https://cloud.google.com/about/locations).\n\nThe Cloud Healthcare API is available in the following regions:\n\n### Regional locations\n\n### Multi-regional locations\n\nLocation quota requests\n-----------------------\n\nYou can request a quota increase for the Cloud Healthcare API in a specific\n[region](/healthcare-api/docs/regions), or in a [multi-region location](/healthcare-api/docs/regions#multi-regional_locations).\n\nTo request a quota increase in a single region: In your quota increase request,\nspecify the region.\n\nTo request a quota increase in a multi-region location:\n\n- For a quota increase in the `us` multi-region, state in your request that the quota is for \"US meta region.\"\n- For a quota increase in the `eu` multi-region, state in your request that the quota is for \"EU meta region.\"\n\nLocation considerations\n-----------------------\n\nWhen you choose a location for your data, you might want to consider factors\nsuch as:\n\n- Regulatory requirements about where to store your data\n- Latency\n- Resiliency\n- Cost\n- Colocation with other Google Cloud services\n\nFor example,\nGoogle manages [multi-regional locations](/docs/geography-and-regions#multi-regional_resources)\nto be redundant and distributed within and\nacross regions. These services optimize availability, performance, and\nresource efficiency. As a result, these services require a trade-off on either\nlatency or the consistency model.\n\nConsider doing the following when choosing a location for your data:\n\n- **Colocate your dataset and your external data source**.\n\n- **Colocate your dataset with your Cloud Storage buckets when importing data**.\n\n- **Colocate your dataset with your Cloud Storage buckets and BigQuery datasets when exporting data**.\n\nMoving Cloud Healthcare API data between locations\n--------------------------------------------------\n\nYou cannot change the location of a dataset after it is created. Also, you\ncannot move a dataset from one location to another. If you need to move data\nfrom one location to another, complete one of the following processes:\n\n### FHIR data\n\n1. [Export](/healthcare-api/docs/how-tos/fhir-import-export#exporting_fhir_resources)\n the data from your FHIR stores to a regional or multi-regional\n Cloud Storage bucket. When you export the data, the operation only exports\n the current version of each resource. The operation does not export version\n history; there is no bulk export operation for version history.\n\n There are [charges](https://cloud.google.com/healthcare-api/pricing#etl_operations) for exporting\n FHIR data to Cloud Storage. You also incur charges for\n [storing the exported data](/storage/pricing#storage-pricing)\n in Cloud Storage.\n2. After you transfer the data to a Cloud Storage bucket,\n create a new dataset in the new location. Create any FHIR stores in the new\n dataset that you require for storing your data. Then, [import](/healthcare-api/docs/how-tos/fhir-import-export#importing_fhir_resources)\n your data from Cloud Storage into the new FHIR stores.\n\n### DICOM data\n\n1. [Export](/healthcare-api/docs/how-tos/dicom-import-export#exporting_dicom_instances)\n the data from your DICOM stores to a regional or multi-regional\n Cloud Storage bucket.\n\n There are [charges](https://cloud.google.com/healthcare-api/pricing#etl_operations) for exporting\n DICOM data to Cloud Storage. You also incur charges for\n [storing the exported data](/storage/pricing#storage-pricing)\n in Cloud Storage.\n2. After you transfer the data to a Cloud Storage bucket,\n create a new dataset in the new location. Create any DICOM stores in the new\n dataset that you require for storing your data. Then, [import](/healthcare-api/docs/how-tos/dicom-import-export#importing_dicom_objects)\n your data from Cloud Storage into the new DICOM stores.\n\n### HL7v2 data\n\n1. [Export the HL7v2 messages](/healthcare-api/docs/how-tos/hl7v2-import-export#exporting_hl7v2_messages)\n from your HL7v2 store to a regional or multi-regional\n Cloud Storage bucket.\n\n There are [charges](https://cloud.google.com/healthcare-api/pricing#etl_operations) for exporting\n HL7v2 messages to Cloud Storage. You also incur charges for\n [storing the exported data](/storage/pricing#storage-pricing)\n in Cloud Storage.\n2. After you transfer the data to a Cloud Storage bucket,\n create a new dataset in the new location. Create any HL7v2 stores in the new\n dataset that you require for storing your data. Then, [import](/healthcare-api/docs/how-tos/hl7v2-import-export)\n your messages from Cloud Storage into the new HL7v2 stores."]]
