Transição para a API v1

Nesta página, explicamos as principais diferenças entre a v1beta1 e a v1 da API Cloud Healthcare. Ele também fornece exemplos de como fazer a transição da v1beta1 para a v1.

Caminhos REST

Todos os caminhos REST para a API Cloud Healthcare agora usam v1 em vez de v1beta1. Exemplo:

v1beta1:

GET https://healthcare.googleapis.com/v1beta1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID

v1:

GET https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID

Alterações DICOM

Pesquisar transações

Na v1beta1, os métodos Search transaction retornaram um código de resposta 200 se a pesquisa tiver sido bem-sucedida, mas não houver resultados correspondentes à consulta.

Para alinhar-se ao padrão DICOM PS3.18 - Web Services, os métodos de transação de pesquisa na v1 retornam um código de resposta 204 em vez de um código de resposta 200.

Métodos de exclusão de DICOMweb

Na v1beta1, os seguintes métodos retornaram um código de resposta vazio quando executado com êxito:

Na v1, 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

Há duas alterações na resposta de chamar projects.locations.datasets.dicomStores.import:

  • Na v1beta1, o método projects.locations.datasets.dicomStores.import retornou uma resposta ImportDicomDataErrorDetails. Na v1, o método não retorna essa resposta. Em vez disso, você pode ver detalhes sobre os erros no Cloud Logging.
  • Na v1beta1, o método projects.locations.datasets.dicomStores.import retornou uma operação de longa duração contendo "type.googleapis.com/google.protobuf.Empty" no campo type da resposta. Na v1, a operação de longa duração contém "type.googleapis.com/google.cloud.healthcare.v1beta1.dicom.ImportDicomDataResponse" no campo type da resposta. Exemplo:

    API Cloud Healthcare v1beta1API Cloud Healthcare v1
    
    "response": {
      "@type": "type.googleapis.com/google.protobuf.Empty"
    }
    
    "response": {
      "@type": "type.googleapis.com/google.cloud.healthcare.v1.dicom.ImportDicomDataResponse"
    }

Como exportar dados DICOM para o Cloud Storage e a resposta do BigQuery

Na v1beta1, o método projects.locations.datasets.dicomStores.export retornou uma operação de longa duração contendo "type.googleapis.com/google.protobuf.Empty" no campo type da resposta. Na v1, a operação de longa duração contém "type.googleapis.com/google.cloud.healthcare.v1beta1.dicom.ImportDicomDataResponse" no campo type da resposta. Exemplo:

API Cloud Healthcare v1beta1API Cloud Healthcare v1

"response": {
  "@type": "type.googleapis.com/google.protobuf.Empty"
}

"response": {
  "@type": "type.googleapis.com/google.cloud.healthcare.v1.dicom.ExportDicomDataResponse"
}

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

Comando 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/v1/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/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/fhirStores?fhirStoreId=FHIR_STORE_ID" | Select-Object -Expand Content

Esquemas ao exportar para o BigQuery

Na v1beta1, é possível especificar os seguintes tipos de esquema no método projects.locations.datasets.fhirStores.export ao exportar recursos 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 v1, os tipos de esquema SCHEMA_TYPE_UNSPECIFIED e LOSSLESS não estão mais disponíveis. Não há mais um valor de tipo de esquema padrão. Se você não especificar o tipo de esquema ANALYTICS, a API Cloud Healthcare retornará um erro.

Métodos condicionais FHIR

Os métodos condicionais FHIR estão disponíveis na v1beta1, mas não na v1. Os métodos condicionais FHIR são:

Recursos executeBundle

Como os métodos condicionais FHIR não estão disponíveis na v1, não é possível chamar métodos condicionais FHIR em um pacote ao chamar projects.locations.datasets.fhirStores.fhir.executeBundle. Para usar métodos condicionais FHIR ao executar um pacote, use a API v1beta1.

Alterações de desidentificação de dados

Remoção DeidentifyErrorDetails

A resposta DeidentifyErrorDetails não está mais disponível na v1. Em vez disso, você pode ver detalhes sobre os erros no Cloud Logging.

Remoção SuccessResourceCount

Na v1beta1, as seguintes respostas continham um campo SuccessResourceCount:

Na v1, 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, as seguintes respostas continham um campo SuccessStoreCount:

DeidentifyErrorDetails também continha um campo FailureStoreCount.

Na v1, essas respostas não contêm mais um campo SuccessStoreCount ou um campo FailureStoreCount.

Remoção FailureResourceCount

Na v1beta1, as seguintes respostas continham um campo FailureResourceCount:

Na v1, 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.