Aktualisierungen der v1beta1 API

Seit dem 26. August 2020 wird v1beta1 auf eine überarbeitete Version aktualisiert. Auf dieser Seite wird die Version von v1beta1 vor diesem Datum als "vorher v1beta1" bezeichnet. Die Version nach diesem Datum wird als "new v1beta1" bezeichnet. Das geplante Abschlussdatum, ab dem das vorherige v1beta1-Verhalten nicht mehr gültig ist, ist der 22. September 2020.

Auf dieser Seite werden die Aktualisierungen von v1beta1 erläutert, bei denen hauptsächlich die Einstellung und das Hinzufügen von Feldern in Anfragen und Antworten an die und aus der Cloud Healthcare API berücksichtigt werden. Durch die Implementierung dieser Änderungen werden gängige Methoden, Ressourcen, Antworten, Anfragen usw. zwischen v1beta1 und v1 ausgerichtet. In diesem Abschnitt finden Sie auch Beispiele für den Wechsel von der vorherigen v1beta1 zur neuen v1beta1.

Wichtig: Während des Übergangszeitraums zum neuen v1beta1 sind das vorherige Verhalten und die neue Verhalten gültig. Wir empfehlen Ihnen, den Clientcode so zu aktualisieren, dass beide Verhaltenstypen akzeptiert werden. So können Sie sich auf den Zeitpunkt vorbereiten, wenn nur das neue Verhalten akzeptiert wird.

Annotationen ändern

Annotationen importieren und exportieren

In der vorherigen v1beta1-Version wurde von annotationStores.import und annotationStores.export der Parameter annotationStore zur Identifizierung des Annotationsspeichers verwendet. Verwenden Sie in der neuen v1beta1-Version name statt annotationStore, um den Annotationsspeicher zu identifizieren.

Annotationsspeicher auswerten

In der vorherigen v1beta1-Version verwendete annotationStores.evaluate den Parameter evalStore, um den Annotationsspeicher zu identifizieren, der für den Vergleich mit einem Golden Store verwendet wurde. Verwenden Sie in der neuen v1beta1-Version name statt evalStore, um den Annotationsspeicher zu identifizieren, der zum Vergleichen mit einem Golden Store verwendet wird.

ImportAnnotationsErrorDetails und ExportAnnotationsErrorDetails

Die Antworten ImportAnnotationsErrorDetails und ExportAnnotationsErrorDetails wurden in der neuen v1beta1-Version entfernt. Stattdessen können Sie sich Details zu Fehlern in Cloud Logging ansehen.

ImportAnnotationsResponse, ExportAnnotationsResponse und EvaluateAnnotationStoreResponse

• ImportAnnotationsResponse und ExportAnnotationsResponse, die im Feld Operation.response des lang andauernden Import- oder Exportvorgangs enthalten sind, umfassen den annotationStore oder das Feld successCount. Sie können sich die Erfolgs- und Fehlerzahlen stattdessen im Feld Operation.metadata ansehen, das im zurückgegebenen lang andauernden Vorgang zurückgegeben wird.
• EvaluateAnnotationStoreResponse, das im Feld Operation.response des lang andauernden Vorgangs der Bewertung enthalten ist, enthält die Felder evalStore, goldenStore, goldenCount oder matchedCount nicht mehr. Stattdessen können Sie den Wert matchedCount im Feld success in Operation.metadata ermitteln. Zum Ermitteln des Werts goldenCount fügen Sie den Wert des Felds success und den Wert des Felds failure in Operation.metadata hinzu.

Änderungen bei der Daten-De-Identifikation

DeidentifyErrorDetails-Entfernung

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

SuccessResourceCount-Entfernung

In der vorherigen v1beta1-Version enthielten die folgenden Antworten das Feld SuccessResourceCount:

• DeidentifySummary
• DeidentifyErrorDetails
• DeidentifyDicomStoreSummary
• DeidentifyFhirStoreSummary

In der neuen v1beta1-Version enthalten diese Antworten kein SuccessResourceCount-Feld. 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 der vorherigen v1beta1-Version enthielten die folgenden Antworten das Feld SuccessStoreCount:

• DeidentifySummary
• DeidentifyErrorDetails

DeidentifyErrorDetails enthielt auch ein FailureStoreCount-Feld.

Im neuen v1beta1 enthalten diese Antworten nicht mehr das Feld SuccessStoreCount und FailureStoreCount.

FailureResourceCount-Entfernung

In der vorherigen v1beta1-Version enthielten die folgenden Antworten das Feld FailureResourceCount:

• DeidentifySummary
• DeidentifyErrorDetails
• DeidentifyDicomStoreSummary

In der neuen v1beta1-Version enthalten diese Antworten kein FailureResourceCount-Feld. 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.

DICOM-Änderungen

In Transaktionen suchen

In der vorherigen v1beta1-Version haben Suchtransaktions-Methoden den Antwortcode 200 zurückgegeben, wenn die Suche erfolgreich war, aber keine Ergebnisse gefunden wurden, die der Abfrage entsprachen. Der Antworttext enthielt auch ein leeres Array von Ergebnissen.

Zur Anpassung an den DICOM PS3.18 - Web Services-Standard geben die Suchtransaktionsmethoden in der neuen Version v1beta den Antwortcode 204 anstelle des Antwortcodes 200 zurück. Statt ein leeres Array von Ergebnissen zurückzugeben, wird kein Antworttext zurückgegeben.

DICOMweb-Löschmethoden

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

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

In der neuen v1beta1-Version 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

In der vorherigen v1beta1 hat die projects.locations.datasets.dicomStores.import Methode zurückgegeben ImportDicomDataErrorDetails in dem Objekt Operation.error.status.details. Im neuen v1beta1 gibt die Methode diese Antwort nicht für Fehler zurück. Stattdessen wird eine URL in Operation.metadata in Cloud Logging eingefügt, wo Sie Details zu etwaigen Fehlern anzeigen können.

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

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 und ExportResourcesErrorDetails

Im vorherigen v1beta1 gab projects.locations.datasets.fhirStores.import und projects.locations.datasets.fhirStores.export einen lang andauernden Vorgang mit ImportResourcesResponse bzw. ExportResourcesResponse im Feld Operation.response zurück. Wenn Fehler aufgetreten sind, wurden ImportResourcesErrorDetails oder ExportResourcesErrorDetails im Feld Operation.error zurückgegeben.

In der neuen v1beta1-Version werden diese Antworten im Feld Operation.metadata als Erfolgs- und Fehleranzahl zurückgegeben.

Schemas beim Exportieren nach BigQuery

In der vorherigen 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.

Im neuen v1beta1 ist der Schematyp SCHEMA_TYPE_UNSPECIFIED nicht mehr verfügbar. Wenn Sie SCHEMA_TYPE_UNSPECIFIED angeben oder das Feld schemaType nicht festlegen, gibt die Cloud Healthcare API einen Fehler zurück.

Änderungen der Standorte

Für die Methoden projects.locations.get und projects.locations.list sind jetzt folgende Berechtigungen erforderlich:

• locations.get: healthcare.locations.get für den angeforderten Standort.
• locations.list: healthcare.locations.list für das übergeordnete Google Cloud-Projekt.