Aggiornamenti all'API v1beta1

A partire dal 26 agosto 2020, v1beta1 ha iniziato a eseguire l'aggiornamento a una versione rivista. In questa pagina, la versione v1beta1 precedente a questa data è indicata come "v1beta1 precedente". La versione successiva a questa data è definita "nuova v1beta1". La data di completamento pianificata quando il precedente comportamento v1beta1 non verrà più accettato è il 22 settembre 2020.

Questa pagina illustra gli aggiornamenti apportati a v1beta1, che riguardano principalmente il ritiro e l'aggiunta di campi nelle richieste e nelle risposte da e verso l'API Cloud Healthcare. L'implementazione di queste modifiche garantisce l'allineamento tra i metodi, le risorse, le risposte, le richieste e così via comuni tra le versioni v1beta1 e v1. Questa sezione fornisce anche esempi di come passare dalla precedente v1beta1 alla nuova versione v1beta1.

Importante: durante il periodo di transizione alla nuova versione v1beta1, il comportamento precedente e il nuovo comportamento sono entrambi validi. Ti consigliamo di aggiornare il codice client per adattarlo a entrambi i tipi di comportamento, in modo da prepararti al momento in cui verrà accettato solo il nuovo comportamento.

Modifiche alle annotazioni

Importazione ed esportazione di annotazioni

Nella precedente v1beta1, annotationStores.import e annotationStores.export utilizzavano il parametro annotationStore per identificare l'archivio di annotazioni. Nella nuova versione v1beta1, utilizza name anziché annotationStore per identificare l'archivio di annotazioni.

Valutazione degli archivi di annotazioni

Nella precedente v1beta1, annotationStores.evaluate ha utilizzato il parametro evalStore per identificare l'archivio di annotazioni utilizzato per il confronto con uno dorato. Nel nuovo v1beta1, utilizza name anziché evalStore per identificare l'archivio di annotazioni utilizzato per il confronto con uno store finale.

ImportAnnotationsErrorDetails e ExportAnnotationsErrorDetails

Le risposte ImportAnnotationsErrorDetails e ExportAnnotationsErrorDetails sono state rimosse nella nuova versione v1beta1. Puoi invece visualizzare i dettagli su eventuali errori in Cloud Logging.

ImportAnnotationsResponse, ExportAnnotationsResponse e EvaluateAnnotationStoreResponse

• ImportAnnotationsResponse e ExportAnnotationsResponse, contenuti nel campo Operation.response dell'operazione di importazione o esportazione a lunga esecuzione, non includono più il campo annotationStore o il campo successCount. Puoi invece visualizzare il numero di operazioni riuscite e non riuscite nel campo Operation.metadata restituito nell'operazione a lunga esecuzione restituita.
• EvaluateAnnotationStoreResponse, contenuto nel campo Operation.response dell'operazione a lunga esecuzione della valutazione, non include più i campi evalStore, goldenStore, goldenCount o matchedCount. Per trovare invece il valore matchedCount, visualizza il campo success in Operation.metadata. Per trovare il valore goldenCount, aggiungi il valore del campo success e il valore del campo failure in Operation.metadata.

Modifiche all'anonimizzazione dei dati

Rimozione di DeidentifyErrorDetails

La risposta DeidentifyErrorDetails non è più disponibile nella nuova versione v1beta1. Puoi invece visualizzare i dettagli su eventuali errori in Cloud Logging.

Rimozione di SuccessResourceCount

Nella precedente v1beta1, le seguenti risposte contenevano un campo SuccessResourceCount:

• DeidentifySummary
• DeidentifyErrorDetails
• DeidentifyDicomStoreSummary
• DeidentifyFhirStoreSummary

Nella nuova versione v1beta1, queste risposte non contengono più un campo SuccessResourceCount. Puoi invece visualizzare le risorse che l'API Cloud Healthcare ha anonimizzato correttamente nel campo progress_counter.success della risposta dell'operazione a lunga esecuzione.

Rimozione di SuccessStoreCount e FailureStoreCount

Nella precedente v1beta1, le seguenti risposte contenevano un campo SuccessStoreCount:

• DeidentifySummary
• DeidentifyErrorDetails

DeidentifyErrorDetails conteneva anche un campo FailureStoreCount.

Nella nuova versione v1beta1, queste risposte non contengono più un campo SuccessStoreCount o un campo FailureStoreCount.

Rimozione di FailureResourceCount

Nella precedente v1beta1, le seguenti risposte contenevano un campo FailureResourceCount:

• DeidentifySummary
• DeidentifyErrorDetails
• DeidentifyDicomStoreSummary

Nella nuova versione v1beta1, queste risposte non contengono più un campo FailureResourceCount. Puoi invece visualizzare le risorse che l'API Cloud Healthcare non è riuscita a anonimizzare nel campo progress_counter.failure della risposta dell'operazione a lunga esecuzione.

Modifiche DICOM

Cerca transazioni

Nella versione precedente v1beta1, i metodi per transazione di ricerca hanno restituito un codice di risposta 200 se la ricerca ha avuto esito positivo, ma non sono stati trovati risultati corrispondenti alla query. Anche il corpo della risposta conteneva un array vuoto di risultati.

Per allinearsi con lo standard dei servizi web PS3.18 DICOM, i metodi di transazione di ricerca nel nuovo v1beta1 restituiscono un codice di risposta 204 anziché un codice di risposta 200. Anziché restituire un array vuoto di risultati, non viene restituito alcun corpo della risposta.

Metodi di eliminazione DICOMweb

Nella precedente v1beta1, i seguenti metodi hanno restituito un codice di risposta vuoto dopo l'esecuzione corretta:

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

Nella nuova versione v1beta1, i metodi restituiscono un'operazione a lunga esecuzione. L'operazione a lunga esecuzione contiene done: true al termine dell'eliminazione.

importazione dei dati DICOM dalla risposta di Cloud Storage

Nella precedente versione v1beta1, il metodo projects.locations.datasets.dicomStores.import ha restituito ImportDicomDataErrorDetails nell'oggetto Operation.error.status.details. Nella nuova versione v1beta1, il metodo non restituisce questa risposta per errori. In Operation.metadata, invece, un URL viene compilato in Cloud Logging, dove puoi visualizzare i dettagli di eventuali errori.

Modifiche FHIR

Creazione di archivi FHIR

Quando crei un archivio FHIR, devi specificare una versione FHIR (DSTU2, STU3 o R4) per l'archivio. Se non specifichi una versione, l'API Cloud Healthcare restituisce un errore.

Ad esempio:

gcloud

Il seguente esempio mostra come creare un archivio 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 e ExportResourcesErrorDetails

Nella precedente v1beta1, projects.locations.datasets.fhirStores.import e projects.locations.datasets.fhirStores.export hanno restituito un'operazione a lunga esecuzione contenente rispettivamente ImportResourcesResponse e ExportResourcesResponse nel campo Operation.response. Se si sono verificati errori, nel campo Operation.error sono stati restituiti ImportResourcesErrorDetails o ExportResourcesErrorDetails.

Nella nuova versione v1beta1, queste risposte vengono restituite come numero di successi e di errori nel campo Operation.metadata.

Schemi durante l'esportazione in BigQuery

Nella precedente versione v1beta1, potevi specificare i seguenti tipi di schema nel metodo projects.locations.datasets.fhirStores.export durante l'esportazione delle risorse FHIR in BigQuery:

• SCHEMA_TYPE_UNSPECIFIED: nessun tipo di schema specificato. Uguale a LOSSLESS.
• LOSSLESS Uno schema basato sui dati generato dai campi presenti nei dati FHIR da esportare, senza ulteriore semplificazione.
• ANALYTICS: schema di analisi definito dalla community FHIR. Vedi https://github.com/FHIR/sql-on-fhir/blob/master/sql-on-fhir.md.

Nella nuova versione v1beta1, il tipo di schema SCHEMA_TYPE_UNSPECIFIED non è più disponibile. Se specifichi SCHEMA_TYPE_UNSPECIFIED o non imposti il campo schemaType, l'API Cloud Healthcare restituisce un errore.

Modifiche alle località

I metodi projects.locations.get e projects.locations.list ora richiedono le seguenti autorizzazioni:

• locations.get: healthcare.locations.get nella posizione richiesta.
• locations.list: healthcare.locations.list sul progetto Google Cloud principale.