Atualizações para a API v1beta1

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 e ExportAnnotationsResponse, contidos no campo Operation.response da operação de longa execução da importação ou da exportação, não incluem mais o parâmetro annotationStore ou no campo successCount. Em vez disso, é possível ver as contagens de êxito e falha no campo Operation.metadata retornado na operação de longa duração retornada.
EvaluateAnnotationStoreResponse, contido no campo Operation.response da operação de longa duração da avaliação, não inclui mais os campos evalStore, goldenStore, goldenCount e matchedCount. Em vez disso, para encontrar o valor matchedCount, consulte o campo success em Operation.metadata. Para localizar o valor goldenCount, adicione o valor do campo success e o valor do campo failure em Operation.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:

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 a LOSSLESS.
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.