Actualizaciones a la API de v1beta1

A partir del 26 de agosto de 2020, la versión v1beta1 comenzó a actualizar a una versión revisada. En esta página, la versión de v1beta1 antes de esa fecha se denomina la “versión v1beta1 anterior”. La versión posterior a esa fecha se denomina “nueva versión v1beta1”. La fecha de finalización programada para cuando el comportamiento anterior de v1beta1 ya no se aceptará es el 22 de septiembre de 2020.

En esta página, se explican las actualizaciones realizadas a la versión v1beta1, que son principalmente importantes para la baja y la adición de campos en solicitudes y respuestas desde y hacia la API de Cloud Healthcare. La implementación de estos cambios garantiza que se alineen los métodos, recursos, respuestas, solicitudes comunes, etc., entre las versiones v1beta1 y v1. En esta sección, también se proporcionan ejemplos de cómo hacer la transición de la versión v1beta1 anterior a la versión v1beta1 nueva.

Importante: Durante el período de transición a la nueva v1beta1, el comportamiento anterior y el nuevo son válidos. Recomendamos actualizar el código de cliente a fin de que se adapte a los tipos de comportamiento a fin de prepararse para cuándo solo se acepte el nuevo comportamiento.

Cambios en las anotaciones

Importa y exporta anotaciones

En la versiones v1beta1 annotationStores.import y annotationStores.export anteriores, se usó el parámetro annotationStore para identificar el almacén de anotaciones. En la versión v1beta1 nueva, se usa name en lugar de annotationStore para identificar el almacén de anotaciones.

Evaluar los almacenes de anotaciones

En la versión v1beta1 anterior, annotationStores.evaluate, se usó el parámetro evalStore a fin de identificar el almacén de anotaciones que se usó para comparar con un almacén dorado. En la versión v1beta1 nueva, se usa name en lugar de evalStore a fin de identificar el almacén de anotaciones usado para compararlo con un almacén dorado.

ImportAnnotationsErrorDetails y ExportAnnotationsErrorDetails

Las respuestas ImportAnnotationsErrorDetails y ExportAnnotationsErrorDetails se quitaron en la versión v1beta1 nueva. En su lugar, puedes ver detalles sobre cualquier error en Cloud Logging.

ImportAnnotationsResponse, ExportAnnotationsResponse y EvaluateAnnotationStoreResponse

• Las ImportAnnotationsResponse y ExportAnnotationsResponse, que se encuentran en el campo Operation.response de la operación de larga duración de la importación o exportación, ya no incluyen el campo annotationStore o successCount. En su lugar, puedes ver los recuentos de errores y fallas en el campo Operation.metadata que se muestra en la operación de larga duración.
• EvaluateAnnotationStoreResponse, que se encuentra en el campo Operation.response de la operación de larga duración de la evaluación, ya no incluye evalStore, goldenStore, goldenCount o matchedCount. En su lugar, para encontrar el valor matchedCount, consulta el campo success en Operation.metadata. Para encontrar el valor goldenCount, agrega el valor del campo success y el valor del campo failure en Operation.metadata.

Cambios en la desidentificación de datos

Eliminación de DeidentifyErrorDetails

La respuesta DeidentifyErrorDetails ya no está disponible en la versión v1beta1 nueva. En su lugar, puedes ver detalles sobre cualquier error en Cloud Logging.

Eliminación de SuccessResourceCount

En la versión v1beta1 anterior, las siguientes respuestas contenían un campo SuccessResourceCount:

• DeidentifySummary
• DeidentifyErrorDetails
• DeidentifyDicomStoreSummary
• DeidentifyFhirStoreSummary

En la versión v1beta1 nueva, estas respuestas ya no contienen un campo SuccessResourceCount. En su lugar, puedes ver los recursos que la API de Cloud Healthcare desidentificó correctamente en el campo progress_counter.success de la respuesta de la operación de larga duración.

Eliminación de SuccessStoreCount y FailureStoreCount

En la versión v1beta1 anterior, las siguientes respuestas contenían un campo SuccessStoreCount:

• DeidentifySummary
• DeidentifyErrorDetails

DeidentifyErrorDetails también contenía un campo FailureStoreCount.

En la versión v1beta1 nueva, estas respuestas ya no contienen un campo SuccessStoreCount o un campo FailureStoreCount.

Eliminación de FailureResourceCount

En la versión v1beta1 anterior, las siguientes respuestas contenían un campo FailureResourceCount:

• DeidentifySummary
• DeidentifyErrorDetails
• DeidentifyDicomStoreSummary

En la versión v1beta1 nueva, estas respuestas ya no contienen un campo FailureResourceCount. En su lugar, puedes ver los recursos que la API de Cloud Healthcare no logró desidentificar en el campo progress_counter.failure de la respuesta de la operación de larga duración.

Cambios de DICOM

Busca transacciones

En la versión v1beta1, los métodos de transacción de búsqueda mostraron un código de respuesta 200 si la búsqueda se realiza correctamente, pero no hubo resultados que coincidieran con la consulta. El cuerpo de la respuesta también contenía un arreglo de resultados vacío.

A fin de alinearse con la PS3.18 de DICOM: Estándar de servicios web, los métodos de transacción de búsqueda en la versión v1beta1 nueva muestran un código de respuesta 204 en lugar de un código de respuesta 200. En lugar de mostrar un arreglo vacío de resultados, no se muestra ningún cuerpo de respuesta.

Métodos de eliminación de DICOMweb

En la versión v1beta1 anterior, los siguientes métodos mostraron un código de respuesta vacío cuando se ejecutaba de forma correcta:

• projects.locations.datasets.dicomStores.studies.delete
• projects.locations.datasets.dicomStores.studies.series.delete

En la versión v1beta1, los métodos muestran una operación de larga duración. La operación de larga duración contiene done: true cuando se completa la eliminación.

Importa datos de DICOM desde la respuesta de Cloud Storage

En la versión v1beta1 anterior, el metodo projects.locations.datasets.dicomStores.import mostró ImportDicomDataErrorDetails en el objeto Operation.error.status.details. En la versión v1beta1 nueva, el método no muestra esta respuesta para errores. En su lugar, se propaga una URL en Operation.metadata a Cloud Logging, en la que puedes ver detalles sobre cualquier error.

Cambios de FHIR

Creación de la tienda de FHIR

Cuando creas una tienda de FHIR, debes especificar una versión de FHIR (DSTU2, STU3 o R4) para la tienda. Si no especificas una versión, la API de Cloud Healthcare muestra un error.

Por ejemplo:

gcloud

En el siguiente ejemplo, se muestra cómo crear una tienda 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 y ExportResourcesErrorDetails

En la versión v1beta1, projects.locations.datasets.fhirStores.import y projects.locations.datasets.fhirStores.export se mostró una operación de larga duración que contiene ImportResourcesResponse y ExportResourcesResponse, respectivamente, en el campo Operation.response. Si se produjo algún error, ImportResourcesErrorDetails o ExportResourcesErrorDetails se mostraron en el campo Operation.error.

En la nueva versión v1beta1, estas respuestas se muestran como recuento de errores y fallas en el campo Operation.metadata.

Esquemas durante la exportación a BigQuery

En la versión v1beta1 anterior, podías especificar los siguientes tipos de esquemas en el método projects.locations.datasets.fhirStores.export cuando exportabas recursos de FHIR a BigQuery:

• SCHEMA_TYPE_UNSPECIFIED: no se especificó ningún tipo de esquema. Es igual que LOSSLESS.
• LOSSLESS: un esquema basado en datos y generado a partir de los campos presentes en los datos de FHIR que se exportan, sin simplificación adicional.
• ANALYTICS: esquema de estadísticas definido por la comunidad de FHIR. Consulta https://github.com/FHIR/sql-on-fhir/blob/master/sql-on-fhir.md.

En la versión v1beta1, el tipo de esquema SCHEMA_TYPE_UNSPECIFIED ya no está disponible. Si especificas SCHEMA_TYPE_UNSPECIFIED o no estableces el campo schemaType, la API de Cloud Healthcare muestra un error.

Cambios en las ubicaciones

Los métodos projects.locations.get y projects.locations.list ahora requieren los siguientes permisos:

• locations.get: healthcare.locations.get en la ubicación solicitada.
• locations.list: healthcare.locations.list en el proyecto superior de Google Cloud.