Umstellung auf die v1 API

Auf dieser Seite werden die wichtigsten Unterschiede zwischen v1beta1 und v1 der Cloud Healthcare API erläutert. Es enthält auch Beispiele für den Übergang von v1beta1 zu v1.

REST-Pfade

Alle REST-Pfade zur Cloud Healthcare API verwenden jetzt v1 anstelle von v1beta1. Beispiel:

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

DICOM-Änderungen

In Transaktionen suchen

In v1beta1 haben Methoden der Suchtransaktion den Antwortcode 200 zurückgegeben, wenn die Suche erfolgreich war, aber keine Ergebnisse gefunden wurden, die der Abfrage entsprachen.

Zur Anpassung an den DICOM PS3.18 - Web Services-Standard geben die Suchtransaktionsmethoden in Version 1 den Antwortcode 204 anstelle des Antwortcodes 200 zurück.

DICOMweb-Löschmethoden

In v1beta1 haben die folgenden Methoden bei erfolgreicher Ausführung einen leeren Antwortcode zurückgegeben:

In Version 1 geben die Methoden einen lang andauernden Vorgang zurück. Der lang andauernde Vorgang enthält done: true, wenn der Löschvorgang abgeschlossen ist.

DICOM-Daten aus der Cloud Storage-Antwort importieren

Beim Aufrufen von projects.locations.datasets.dicomStores.import gibt es zwei Änderungen an der Antwort:

  • In v1beta1 hat die Methode projects.locations.datasets.dicomStores.import die Antwort ImportDicomDataErrorDetails zurückgegeben. In Version 1 gibt die Methode diese Antwort nicht zurück. Stattdessen können Sie sich Details zu Fehlern in Cloud Logging ansehen.
  • In v1beta1 hat die Methode projects.locations.datasets.dicomStores.import einen lang andauernden Vorgang zurückgegeben, der "type.googleapis.com/google.protobuf.Empty" im Feld type der Antwort enthält. In Version 1 enthält der lang andauernde Vorgang "type.googleapis.com/google.cloud.healthcare.v1beta1.dicom.ImportDicomDataResponse" im Feld type der Antwort. Beispiel:

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

Exportieren von DICOM-Daten in die Cloud Storage- und BigQuery-Antwort

In v1beta1 hat die Methode projects.locations.datasets.dicomStores.export einen lang andauernden Vorgang zurückgegeben, der "type.googleapis.com/google.protobuf.Empty" im Feld type der Antwort enthält. In Version 1 enthält der lang andauernde Vorgang "type.googleapis.com/google.cloud.healthcare.v1beta1.dicom.ImportDicomDataResponse" im Feld type der Antwort. Beispiel:

Cloud Healthcare API v1beta1Cloud Healthcare API v1

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

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

FHIR-Änderungen

FHIR-Speicher erstellen

Wenn Sie einen FHIR-Speicher erstellen, müssen Sie eine FHIR-Version (DSTU2, STU3 oder R4) für den Speicher angeben. Wenn Sie keine Version angeben, gibt die Cloud Healthcare API einen Fehler zurück.

Beispiel:

gcloud

Das folgende Beispiel zeigt, wie Sie einen FHIR-Speicher erstellen.

gcloud beta healthcare fhir-stores create FHIR_STORE_ID \
  --dataset=DATASET_ID \
  --location=LOCATION \
  --version={DSTU2|STU3|R4}

API

curl-Befehl

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

Schemas beim Exportieren nach BigQuery

In v1beta1 können Sie beim Exportieren von FHIR-Ressourcen nach BigQuery in der Methode projects.locations.datasets.fhirStores.export die folgenden Schematypen angeben:

  • SCHEMA_TYPE_UNSPECIFIED: Es wurde kein Schematyp angegeben. Gleich wie bei LOSSLESS.
  • LOSSLESS Ein datengetriebenes Schema, das ohne zusätzliche Vereinfachung aus den Feldern der zu exportierenden FHIR-Daten generiert wird.
  • ANALYTICS: Von der FHIR-Community definiertes Analytics-Schema. Weitere Informationen finden Sie unter https://github.com/FHIR/sql-on-fhir/blob/master/sql-on-fhir.md.

In Version 1 sind die Schematypen SCHEMA_TYPE_UNSPECIFIED und LOSSLESS nicht mehr verfügbar. Es gibt keinen Standardschematyp mehr. Wenn Sie den Schematyp ANALYTICS nicht angeben, gibt die Cloud Healthcare API einen Fehler zurück.

Bedingte FHIR-Methoden

FHIR-bedingte Methoden sind in v1beta1 verfügbar, aber nicht in v1. Die FHIR-bedingten Methoden sind:

executeBundle-Funktionen

Da FHIR-bedingte Methoden in v1 nicht verfügbar sind, können Sie beim Aufrufen von projects.locations.datasets.fhirStores.fhir.executeBundle keine FHIR-bedingten Methoden in einem Bundle aufrufen. Wenn Sie beim Ausführen eines Bundles FHIR-bedingte Methoden verwenden möchten, verwenden Sie die v1beta1 API.

Änderungen bei der Daten-De-Identifikation

DeidentifyErrorDetails-Entfernung

Die Antwort DeidentifyErrorDetails ist in Version 1 nicht mehr verfügbar. Stattdessen können Sie sich Details zu Fehlern in Cloud Logging ansehen.

SuccessResourceCount-Entfernung

In v1beta1 enthielten die folgenden Antworten das Feld SuccessResourceCount:

In Version 1 enthalten diese Antworten kein Feld SuccessResourceCount mehr. Stattdessen können Sie die Ressourcen, die die Cloud Healthcare API erfolgreich de-identifiziert hat, im Feld progress_counter.success der Antwort mit lang andauerndem Vorgang anzeigen.

SuccessStoreCount und FailureStoreCount entfernen

In v1beta1 enthielten die folgenden Antworten das Feld SuccessStoreCount:

DeidentifyErrorDetails enthielt auch ein FailureStoreCount-Feld.

In Version 1 enthalten diese Antworten kein Feld SuccessStoreCount oder FailureStoreCount mehr.

FailureResourceCount-Entfernung

In v1beta1 enthielten die folgenden Antworten das Feld FailureResourceCount:

In Version 1 enthalten diese Antworten kein Feld FailureResourceCount mehr. Stattdessen können Sie die Ressourcen, die von der Cloud Healthcare API nicht de-identifiziert werden konnten, im Feld progress_counter.failure der lang andauernden Vorgangsantwort anzeigen.