A partir de 26 de agosto de 2020, a v1beta1 começou a atualizar para uma versão revisada. Nesta página, a versão v1beta1 anterior a essa data é chamada de "v1beta1 anterior". A versão posterior a essa data é denominada "nova v1beta1". A data de conclusão agendada para quando o comportamento v1beta1 anterior não for mais aceito é 22 de setembro de 2020.
Nesta página, explicamos as atualizações feitas na v1beta1, que se preocupam principalmente com a suspensão do uso e a adição de campos em solicitações e respostas da API Cloud Healthcare. A implementação dessas alterações garante que métodos comuns, recursos, respostas, solicitações etc. entre a v1beta1 e a v1 se alinhem. Nesta seção, também fornecemos exemplos de como fazer a transição da v1beta1 anterior para a nova v1beta1.
Alterações em anotações
Como importar e exportar anotações
Na versão v1beta1 anterior, annotationStores.import
e annotationStores.export
usavam o parâmetro annotationStore
para identificar o armazenamento de anotação. Na nova
v1beta1, use name
em vez de annotationStore
para identificar o armazenamento de
anotações.
Como avaliar repositórios de anotações
Na versão v1beta1 anterior, o annotationStores.evaluate
usava o parâmetro evalStore
para identificar o armazenamento de anotação usado para comparar com um armazenamento
de ouro. Na nova
v1beta1, use name
em vez de evalStore
para identificar o armazenamento de
anotações usado para comparar com um armazenamento de ouro.
ImportAnnotationsErrorDetails
e ExportAnnotationsErrorDetails
As respostas ImportAnnotationsErrorDetails
e ExportAnnotationsErrorDetails
foram removidas na nova v1beta1. Em vez disso, você pode ver
detalhes sobre os erros no Cloud Logging.
ImportAnnotationsResponse
, ExportAnnotationsResponse
e EvaluateAnnotationStoreResponse
ImportAnnotationsResponse
eExportAnnotationsResponse
, contidos no campoOperation.response
da operação de longa execução da importação ou da exportação, não incluem mais o parâmetroannotationStore
ou no camposuccessCount
. Em vez disso, é possível ver as contagens de êxito e falha no campoOperation.metadata
retornado na operação de longa duração retornada.EvaluateAnnotationStoreResponse
, contido no campoOperation.response
da operação de longa duração da avaliação, não inclui mais os camposevalStore
,goldenStore
,goldenCount
ematchedCount
. Em vez disso, para encontrar o valormatchedCount
, consulte o camposuccess
emOperation.metadata
. Para localizar o valorgoldenCount
, adicione o valor do camposuccess
e o valor do campofailure
emOperation.metadata
.
Alterações de desidentificação de dados
Remoção DeidentifyErrorDetails
A resposta
DeidentifyErrorDetails
não está mais disponível na nova v1beta1. Em vez disso, você pode ver detalhes sobre
os erros no
Cloud Logging.
Remoção SuccessResourceCount
Na v1beta1 anterior, as seguintes respostas continham um campo SuccessResourceCount
:
Na nova v1beta1, essas respostas não contêm mais um campo SuccessResourceCount
. Em vez disso, você pode ver os recursos que a API Cloud Healthcare desidentificou com êxito no campo progress_counter.success
da resposta de operação de longa duração.
Remoção de SuccessStoreCount
e FailureStoreCount
Na v1beta1 anterior, as seguintes respostas continham um campo SuccessStoreCount
:
DeidentifyErrorDetails
também continha um campo FailureStoreCount
.
Na nova v1beta1, essas respostas não contêm mais um campo SuccessStoreCount
nem
FailureStoreCount
.
Remoção FailureResourceCount
Na v1beta1 anterior, as seguintes respostas continham um campo FailureResourceCount
:
Na nova v1beta1, essas respostas não contêm mais um campo FailureResourceCount
. Em vez disso, é possível visualizar os recursos que a API Cloud Healthcare não conseguiu desidentificar no campo progress_counter.failure
da resposta da operação de longa duração.
Alterações DICOM
Pesquisar transações
Na v1beta1 anterior, os métodos Search transaction
retornavam um código de resposta 200
se a pesquisa tivesse sido bem-sucedida, mas não havia
resultados correspondentes à consulta. O corpo da resposta também continha uma
matriz de resultados vazia.
Para se alinhar ao
padrão DICOM PS3.18 - Web Services (em inglês),
os métodos de pesquisa de transação na nova v1beta1 retornam um código de resposta 204
em vez de
200
. Em vez de retornar uma matriz vazia de resultados, nenhum
corpo de resposta é retornado.
Métodos de exclusão de DICOMweb
Na v1beta1 anterior, os seguintes métodos retornavam um código de resposta vazio quando executados com êxito:
projects.locations.datasets.dicomStores.studies.delete
projects.locations.datasets.dicomStores.studies.series.delete
Na nova v1beta1, os métodos retornam uma operação de longa duração.
A operação de longa duração contém done: true
quando a exclusão é concluída.
Como importar dados DICOM da resposta do Cloud Storage
Na versão v1beta1 anterior, o método projects.locations.datasets.dicomStores.import
retornou ImportDicomDataErrorDetails
no objeto
Operation.error.status.details
. Na nova v1beta1, o método não retorna essa resposta para erros. Em vez disso, um URL é preenchido
em Operation.metadata
para Cloud Logging, em que é possível visualizar
detalhes sobre quaisquer erros.
Alterações de FHIR
Criação de loja FHIR
Ao criar um armazenamento FHIR, especifique uma versão FHIR (DSTU2, STU3 ou R4) para o armazenamento. Se você não especificar uma versão, a API Cloud Healthcare retornará um erro.
Exemplo:
gcloud
O exemplo a seguir mostra como criar um armazenamento de FHIR.
gcloud beta healthcare fhir-stores create FHIR_STORE_ID \ --dataset=DATASET_ID \ --location=LOCATION \ --version={DSTU2|STU3|R4}
API
curl
curl -X POST \ -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \ -H "Content-Type: application/json; charset=utf-8" \ --data "{ 'version': 'FHIR_STORE_VERSION' }" "https://healthcare.googleapis.com/v1beta1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/fhirStores?fhirStoreId=FHIR_STORE_ID"
PowerShell
$cred = gcloud auth application-default print-access-token $headers = @{ Authorization = "Bearer $cred" } Invoke-WebRequest ` -Method Post ` -Headers $headers ` -ContentType: "application/json; charset=utf-8" ` -Body "{ 'version': 'FHIR_STORE_VERSION' }" ` -Uri "https://healthcare.googleapis.com/v1beta1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/fhirStores?fhirStoreId=FHIR_STORE_ID" | Select-Object -Expand Content
ImportResourcesResponse
, ExportResourcesResponse
, ImportResourcesErrorDetails
e ExportResourcesErrorDetails
Na versão v1beta1 anterior, projects.locations.datasets.fhirStores.import
e projects.locations.datasets.fhirStores.export
retornavam uma operação de longa duração contendo ImportResourcesResponse
e ExportResourcesResponse
,
respectivamente, no campo
Operation.response
. Se ocorresse algum erro, ImportResourcesErrorDetails
ou ExportResourcesErrorDetails
retornavam no campo
Operation.error
.
Na nova v1beta1, essas respostas são retornadas como contagens de sucesso e falha no campo
Operation.metadata
.
Esquemas ao exportar para o BigQuery
Na versão v1beta1 anterior, era possível especificar os seguintes tipos de esquema no método
projects.locations.datasets.fhirStores.export
ao exportar recursos de FHIR para o BigQuery:
SCHEMA_TYPE_UNSPECIFIED
: nenhum tipo de esquema especificado. Igual aLOSSLESS
.LOSSLESS
Um esquema baseado em dados gerado a partir dos campos presentes nos dados FHIR que estão sendo exportados, sem simplificação adicional.ANALYTICS
: esquema do Google Analytics definido pela comunidade FHIR. Consulte https://github.com/FHIR/sql-on-fhir/blob/master/sql-on-fhir.md.
Na nova v1beta1, o tipo de esquema
SCHEMA_TYPE_UNSPECIFIED
não está mais disponível. Se você especificar SCHEMA_TYPE_UNSPECIFIED
ou não definir o campo schemaType
, a API Cloud Healthcare retornará um erro.
Alterações de locais
Os métodos projects.locations.get
e projects.locations.list
agora exigem as seguintes permissões:
locations.get
:healthcare.locations.get
no local solicitado.locations.list
:healthcare.locations.list
no projeto pai do Google Cloud.