Mises à jour de l'API v1beta1

Depuis le 26 août 2020, le passage de la version v1beta1 à une version révisée a commencé. Sur cette page, la version v1beta1 antérieure à cette date est appelée "version v1beta précédente". La version postérieure à cette date est appelée "nouvelle version v1beta1". La date de fin prévue où le comportement de la version v1beta1 précédente ne sera plus accepté est le 22 septembre 2020.

Cette page explique les mises à jour apportées à la version v1beta1, qui concernent principalement l'obsolescence et l'ajout de champs dans les requêtes et les réponses que l'API Cloud Healthcare envoie et reçoit. La mise en œuvre de ces modifications permet de garantir que les méthodes, ressources, réponses, requêtes, etc. sont alignées entre la version v1beta1 et la version v1. Cette section fournit également des exemples de transition de la version v1beta1 précédente vers la nouvelle version v1beta1.

Important : Pendant la période de transition vers la nouvelle version v1beta1, le comportement précédent et le nouveau comportement sont tous deux valides. Nous vous recommandons de mettre à jour le code client pour prendre en charge ces deux types de comportement, afin d'être préparé lorsqu'il n'y aura plus qu'un seul comportement accepté.

Modifications concernant les annotations

Importer et exporter des annotations

Dans la version v1beta1 précédente, annotationStores.import et annotationStores.export utilisaient le paramètre annotationStore pour identifier le magasin d'annotations. Dans la nouvelle version v1beta1, utilisez name au lieu de annotationStore pour identifier le magasin d'annotations.

Évaluer les magasins d'annotations

Dans la version v1beta1 précédente, annotationStores.evaluate utilisait le paramètre evalStore pour identifier le magasin d'annotations utilisé pour établir des comparaisons avec un magasin de référence. Dans la nouvelle version v1beta1, utilisez name au lieu de evalStore pour identifier le magasin d'annotations utilisé pour établir des comparaisons avec un magasin de référence.

ImportAnnotationsErrorDetails et ExportAnnotationsErrorDetails

Les réponses ImportAnnotationsErrorDetails et ExportAnnotationsErrorDetails ont été supprimées dans la nouvelle version v1beta1. À la place, vous pouvez afficher les détails des erreurs dans Cloud Logging.

ImportAnnotationsResponse, ExportAnnotationsResponse et EvaluateAnnotationStoreResponse

• ImportAnnotationsResponse et ExportAnnotationsResponse, qui sont inclus dans le champ Operation.response des opérations d'importation et d'exportation de longue durée, ne comportent plus les champs annotationStore et successCount. À la place, vous pouvez afficher le nombre de succès et d'échecs dans le champ Operation.metadata qui est renvoyé dans l'opération de longue durée retournée.
• EvaluateAnnotationStoreResponse, qui est INCLUS dans le champ Operation.response de l'opération d'évaluation de longue durée, ne comporte plus les champs evalStore, goldenStore, goldenCount ou matchedCount. Pour rechercher la valeur matchedCount, affichez à la place le champ success dans Operation.metadata. Pour trouver la valeur goldenCount, ajoutez la valeur du champ success et celle du champ failure dans Operation.metadata.

Modifications concernant l'anonymisation des données

Suppression de DeidentifyErrorDetails

La réponse DeidentifyErrorDetails n'est plus disponible dans la nouvelle version v1beta1. À la place, vous pouvez afficher les détails des erreurs dans Cloud Logging.

Suppression de SuccessResourceCount

Dans la version v1beta1 précédente, les réponses suivantes contiennent un champ SuccessResourceCount :

• DeidentifySummary
• DeidentifyErrorDetails
• DeidentifyDicomStoreSummary
• DeidentifyFhirStoreSummary

Dans la nouvelle version v1beta1, ces réponses ne contiennent plus de champ SuccessResourceCount. À la place, vous pouvez afficher les ressources que l'API Cloud Healthcare a correctement anonymisées dans le champ progress_counter.success de la réponse d'opération de longue durée.

Suppression de SuccessStoreCount et de FailureStoreCount

Dans la version v1beta1 précédente, les réponses suivantes contiennent un champ SuccessStoreCount :

• DeidentifySummary
• DeidentifyErrorDetails

DeidentifyErrorDetails contenait également un champ FailureStoreCount.

Dans la nouvelle version v1beta1, ces réponses ne contiennent plus les champs SuccessStoreCount et FailureStoreCount.

Suppression de FailureResourceCount

Dans la version v1beta1 précédente, les réponses suivantes contiennent un champ FailureResourceCount :

• DeidentifySummary
• DeidentifyErrorDetails
• DeidentifyDicomStoreSummary

Dans la nouvelle version v1beta1, ces réponses ne contiennent plus de champ FailureResourceCount. À la place, vous pouvez afficher les ressources que l'API Cloud Healthcare n'a pas pu anonymiser dans le champ progress_counter.failure de la réponse d'opération de longue durée.

Modifications DICOM

Rechercher des transactions

Dans la version v1beta1 précédente, les méthodes de recherche renvoyaient un code de réponse 200 si la recherche avait abouti, mais qu'aucun résultat ne correspondait à la requête. Le corps de la réponse contenait également un tableau de résultats vide.

Pour respecter la norme DICOM PS3.18 - Web Services, les méthodes de transaction de recherche de la nouvelle version v1beta1 renvoient un code de réponse 204 au lieu d'un code de réponse 200. Plutôt que de renvoyer un tableau de résultats vide, aucun corps de réponse n'est renvoyé.

Méthodes de suppression DICOMweb

Dans la version v1beta1 précédente, les méthodes suivantes renvoyaient un code de réponse vide lorsque l'exécution aboutissait :

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

Dans la nouvelle version v1beta1, les méthodes renvoient une opération de longue durée. L'opération de longue durée contient done: true une fois la suppression terminée.

Importer des données DICOM à partir de la réponse Cloud Storage

Dans la version v1beta1 précédente, la méthode projects.locations.datasets.dicomStores.import renvoyait ImportDicomDataErrorDetails dans l'objet Operation.error.status.details. Dans la nouvelle version v1beta1, la méthode ne renvoie pas cette réponse pour les erreurs. À la place, une URL vers Cloud Loggingest renseignée dans l'objet Operation.metadata afin que vous puissiez consulter les détails des erreurs.

Modifications FHIR

Création d'un magasin FHIR

Lorsque vous créez un magasin FHIR, vous devez spécifier une version FHIR (DSTU2, STU3 ou R4) pour le magasin. Si vous ne spécifiez pas de version, l'API Cloud Healthcare renvoie une erreur.

Exemple :

gcloud

L'exemple suivant montre comment créer un datastore 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 et ExportResourcesErrorDetails

Dans la version v1beta1 précédente, projects.locations.datasets.fhirStores.import et projects.locations.datasets.fhirStores.export renvoyaient une opération de longue durée contenant ImportResourcesResponse et ExportResourcesResponse, respectivement, dans le champ Operation.response. En cas d'erreur, ImportResourcesErrorDetails ou ExportResourcesErrorDetails était renvoyé dans le champ Operation.error.

Dans la nouvelle version v1beta1, ces réponses renvoient le nombre de succès et d'échecs dans le champ Operation.metadata.

Schémas disponibles lors de l'exportation vers BigQuery

Dans la version v1beta1 précédente, vous pouviez spécifier les types de schémas suivants dans la méthode projects.locations.datasets.fhirStores.export lors de l'exportation de ressources FHIR vers BigQuery :

• SCHEMA_TYPE_UNSPECIFIED : aucun type de schéma n'est spécifié. Même chose pour LOSSLESS.
• LOSSLESS Schéma basé sur les données généré à partir des champs présents dans les données FHIR exportées, sans simplification supplémentaire.
• ANALYTICS : schéma Analytics défini par la communauté FHIR. Consultez la page https://github.com/FHIR/sql-on-fhir/blob/master/sql-on-fhir.md.

Dans la nouvelle version v1beta1, le type de schéma SCHEMA_TYPE_UNSPECIFIED n'est plus disponible. Si vous spécifiez SCHEMA_TYPE_UNSPECIFIED ou que le champ schemaType n'est pas défini, l'API Cloud Healthcare renvoie une erreur.

Modifications concernant les emplacements

Les méthodes projects.locations.get et projects.locations.list nécessitent désormais les autorisations suivantes :

• locations.get : healthcare.locations.get à l'emplacement demandé.
• locations.list : healthcare.locations.list sur le projet Google Cloud parent.