Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Google Cloud usa regiões subdivididas em zonas para definir a localização geográfica dos recursos físicos de computação.
Principais conceitos
Você especifica um local para armazenar os dados da API Cloud Healthcare ao criar um conjunto de dados. Depois que você cria o conjunto de dados, o local não pode ser alterado. Os dados no conjunto de dados são armazenados em repouso no local escolhido.
O local está vinculado à identidade do conjunto de dados e é uma parte permanente do nome do recurso do conjunto de dados.
Todos os armazenamentos de dados no conjunto de dados são atribuídos à mesma região do conjunto de dados.
Há dois tipos de locais:
Um local regional é um lugar geográfico específico, como Tóquio.
Para mais informações, consulte Recursos regionais na página "Geografia e regiões".
Um local multirregional é uma grande área geográfica, como os Estados Unidos, que contém pelo menos dois locais regionais. Para mais informações, consulte Recursos multirregionais na página sobre regiões e localidades geográficas.
Data centers dentro de estados membro da União Europeia
Solicitações de cota de local
É possível solicitar um aumento de cota para a API Cloud Healthcare em uma região específica ou em um local multirregional.
Para solicitar um aumento de cota em uma única região: especifique a região na solicitação.
Para solicitar um aumento de cota em um local multirregional:
Para um aumento de cota na multirregional us, especifique na solicitação que a cota é para a "metarregional dos EUA".
Para um aumento de cota na região múltipla eu, especifique na solicitação que a cota é para a "meta-região da UE".
Considerações sobre o local
Ao escolher um local para seus dados, considere fatores como:
Requisitos regulamentares sobre onde armazenar seus dados
Latência
Resiliência
Custo
Colocation com outros serviços Google Cloud
Por exemplo, o Google gerencia locais multirregionais para serem redundantes e distribuídos entre regiões. Esses serviços otimizam a disponibilidade, o desempenho e a eficiência do recurso. Dessa forma, esses serviços exigem uma contrapartida em termos de latência ou modelo de consistência.
Considere fazer o seguinte ao escolher um local para seus dados:
Colocar o conjunto de dados e a fonte de dados externa.
Colocar o conjunto de dados com os intervalos do Cloud Storage ao importar dados.
Colocar o conjunto de dados com os intervalos do Cloud Storage e os conjuntos de dados do BigQuery ao exportar dados.
Como mover dados da API Cloud Healthcare entre locais
Não é possível alterar o local de um conjunto de dados depois que ele foi criado. Além disso, não é possível mover um conjunto de dados de um local para outro. Se você precisar mover dados de um local para outro, conclua um dos seguintes processos:
Dados FHIR
Exporte os dados dos seus armazenamentos FHIR para um bucket regional ou multirregional do Cloud Storage. Quando você exporta os dados, a operação exporta apenas a versão atual de cada recurso. A operação não exporta o histórico de versões. não há operação de exportação em massa para o histórico de versões.
Depois de transferir os dados para um bucket do Cloud Storage, crie um novo conjunto de dados no novo local. Crie qualquer armazenamento de FHIR no novo conjunto de dados necessário para armazenar seus dados. Em seguida, importe seus dados do Cloud Storage para os novos armazenamentos de FHIR.
Dados DICOM
Exporte os dados dos seus armazenamentos DICOM para um bucket regional ou multirregional do Cloud Storage.
Depois de transferir os dados para um bucket do Cloud Storage, crie um novo conjunto de dados no novo local. Crie qualquer armazenamento DICOM no novo conjunto de dados necessário para armazenar seus dados. Em seguida, importe seus dados do Cloud Storage para os novos armazenamentos DICOM.
Dados HL7v2
Exporte as mensagens HL7v2
do seu armazenamento HL7v2 para um bucket regional ou multirregional
do Cloud Storage.
Depois de transferir os dados para um bucket do Cloud Storage, crie um novo conjunto de dados no novo local. Crie qualquer armazenamento HL7v2 no novo
conjunto de dados necessário para armazenar seus dados. Em seguida, importe
as mensagens do Cloud Storage para os novos armazenamentos HL7v2.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-18 UTC."],[[["\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."]]
