Informazioni sullo schema DICOM di BigQuery

Questa pagina descrive lo schema della tabella BigQuery creata durante l'esportazione dei metadati DICOM in BigQuery.

Terminologia

Per comprendere lo schema e i suoi componenti, acquisisci familiarità con la terminologia DICOM. In particolare, questa pagina utilizza diversi termini presenti in 3.10 DICOM Data Structures and Encoding Definitions.

Panoramica

L'API Cloud Healthcare genera automaticamente lo schema BigQuery utilizzando i dati che stai esportando e il dizionario DICOM. Lo schema contiene solo colonne per gli elementi di dati DICOM presenti nei metadati. L'unica eccezione è Person Name VR.

Quando esporta i metadati DICOM, l'API Cloud Healthcare tenta di esportare tutti gli elementi di dati nei metadati. Per informazioni su cosa succede in caso di problemi, consulta la sezione Tipi in conflitto e non corrispondenti.

Elementi di dati standard e privati

DICOM fornisce elementi di dati standard conformi a una specifica predefinita. Per un elenco di questi elementi di dati, consulta Registro degli elementi di dati DICOM.

Nei casi in cui devi comunicare dati non conformi agli elementi standard, puoi utilizzare gli elementi di dati privati.

Elementi di dati standard

I seguenti comportamenti si applicano agli elementi di dati standard. Per il comportamento degli elementi di dati privati, vedi Elementi di dati privati.

Nomi delle colonne

Le colonne nello schema BigQuery generato vengono denominate in base alla parola chiave dell'elemento di dati. Ad esempio, se i metadati DICOM contengono un elemento di dati la cui parola chiave è InstanceCreationDate, lo schema generato ha una colonna corrispondente denominata InstanceCreationDate.

Comportamento standard degli elementi di dati DICOM

La tabella seguente mostra un elenco di rappresentazioni di valori (VR) e le relative abbreviazioni. Per qualsiasi elemento di dati esportato in BigQuery che contenga uno di questi VR, l'elemento di dati utilizza il tipo di dati BigQuery riportato in "Tipo di dati":

VR Tipo di dati
  • Entità applicazione (AE)
  • Stringa di età (AS)
  • Stringa di codice (CS)
  • Stringa lunga (LO)
  • Testo lungo (LT)
  • Short String (SH)
  • Testo breve (ST)
  • Caratteri illimitati (UC)
  • Identificatore univoco (UI/UID)
  • Identificatore universale di risorse (URI) o Uniform Resource Locator (URI/URL)
  • SMS illimitati (UT)
 Stringa
Data (DA) Data
Tempo (TM) Ora
Data e ora (DT) Timestamp
  • Stringa decimale (DS)
  • Stringa di numeri interi (IS)
 Stringa
Nome della persona (PN) Struct (Record)
  • Floating Point Single (FL)
  • Floating Point Double (FD)
 Punto mobile
  • Tag attributo (AT)
  • Signed Long (SL)
  • Short firmato (SS)
  • Unsigned Long (UL)
  • Short senza contratto (Stati Uniti)
 Numero intero
Sequenza di elementi (SQ) Struct (Record)

Modalità Nullable e Repeated

A seconda del valore di Value Multiplicity (VM) di un elemento di dati, la colonna BigQuery ha una delle due modalità: NULLABLE o REPEATED.

Se un elemento di dati ha un valore VM pari a 1, il che indica che l'elemento di dati è univoco, l'elemento di dati utilizza la modalità NULLABLE. Per qualsiasi altro valore della VM, l'elemento di dati utilizza la modalità REPEATED.

Ad esempio, come mostrato nel Registro degli elementi di dati DICOM, la parola chiave SOPInstanceUID ha un valore VM pari a 1. Di conseguenza, quando viene esportato in BigQuery, la modalità è NULLABLE, e la sua rappresentazione nella tabella è simile alla seguente (se rappresentata come JSON):

"SOPInstanceUID": "0.0.000.000000.0.000.0000.0000000.0000.0000000000.000",

Al contrario, la parola chiave ImageType ha un valore VM pari a 2-n. Di conseguenza, quando viene esportato in BigQuery, la modalità è REPEATED e la rappresentazione nella tabella è simile alla seguente (se rappresentata come JSON):

"ImageType": [
  "ORIGINAL",
  "PRIMARY",
  "OTHER",
  "..."
],

VR escluse

I dati binari e in formato lungo non vengono esportati nella tabella BigQuery generata, pertanto gli elementi di dati contenenti i seguenti VR non vengono esportati. Al contrario, i seguenti VR sono inclusi in una colonna separata (denominata DroppedTags.TagName) nella tabella BigQuery di destinazione.

  • Altro doppio (OD)
  • Altro float (OF)
  • Titolo lungo: altri problemi (OL)
  • Altro byte (OB)
  • Altra parola (OW)
  • Sconosciuto (ONU)
  • Tag Sequence (SQ) contenenti più di circa 1 MiB di dati
  • Attributo (AT), Virgola mobile doppia (FD), Virgola mobile singola (FL), Intero lungo senza segno (UL) o Intero corto senza segno (US), se la molteplicità del valore (VM) è maggiore di 512.
    • Per motivi legacy, i tag delle istanze già inserite nell'API Cloud Healthcare potrebbero essere inclusi nella colonna DroppedTags.TagName se la molteplicità dei valori è superiore a 64.

Person Name VR

Ogni colonna nello schema BigQuery con un VR Nome persona (PN) contiene sempre tre colonne secondarie, indipendentemente dal fatto che le colonne secondarie contengano dati. Le tre colonne secondarie sono:

  • Alfabetico
  • Ideografico
  • Fonetico

Ognuna delle tre colonne secondarie ha le proprie cinque colonne secondarie:

  • FamilyName
  • GivenName
  • MiddleName
  • NamePrefix
  • NameSuffix

Ad esempio, considera il tag pubblico "OperatorsName (0008,1070)", che ha un VR di Person Name (PN). Supponiamo che il valore di OperatorsName sia "Darcy Smith". Lo schema conterrà una colonna OperatorsName contenente le sottocolonne elencate in precedenza, ma solo Alphabetic.FamilyName (Smith) e Alphabetic.GivenName (Darcy) conterranno valori.

Elementi di dati privati

Alcune implementazioni cliniche potrebbero richiedere l'archiviazione di dati personalizzati che non rientrano nella struttura degli elementi di dati pubblici. In alternativa, puoi utilizzare elementi di dati privati.

Gli elementi di dati privati con un VR di SQ (Sequence of Items) hanno lo stesso comportamento degli elementi di dati standard. Gli elementi di dati privati con un VR di SQ sono chiamati sequenze di dati privati.

Gli elementi di dati privati che non hanno un VR di SQ sono nidificati in una colonna denominata OtherElements e vengono convertiti in stringhe. Questi elementi di dati privati sono chiamati dati privati non sequenziali. Per interrogare elementi di dati privati non sequenziali, la query deve eseguire la ricerca all'interno della colonna OtherElements dell'elemento.

La colonna OtherElements contiene due sottocolonne: "Dati" e "Tag". La colonna Dati è la rappresentazione stringa del valore dell'elemento di dati privati. È sempre di tipo REPEATED. La colonna Tag utilizza il formato "Tag_HEX", dove HEX è una stringa esadecimale del numero del tag.

LastUpdated e Type colonne

Le colonne LastUpdated e Type vengono aggiunte alla tabella BigQuery creata quando esporti i metadati DICOM. Queste colonne non sono elementi di dati standard o privati e non corrispondono al Registro degli elementi di dati DICOM.

Il comportamento di queste colonne è il seguente:

  • La colonna LastUpdated contiene un valore timestamp che indica quando l'istanza DICOM è stata inserita o eliminata dall'archivio DICOM.
  • La colonna Type contiene una stringa che mostra il tipo di operazione eseguita. I valori possibili sono CREATE o DELETE.

Tipi in conflitto e non corrispondenti

Se si verifica un conflitto di tipo, ad esempio quando un tag pubblico viene utilizzato con un tipo errato, il tag pubblico viene trattato come se fosse un tag privato. Il valore dell'elemento di dati è nidificato in una colonna denominata OtherElements e il valore viene convertito in una stringa.

Ad esempio, supponiamo che i metadati DICOM contengano un tag con:

  • Un numero di tag "(4010,1017)"
  • VR di SL (Signed Long)
  • Un valore di 32

(4010,1017) è lo stesso numero di tag di "Massa", che è un nome di tag pubblico nella specifica DICOM con un VR di FL. L'operazione di esportazione prevede che un elemento di dati con il numero di tag "(4010,1017)" sia il nome del tag pubblico "Massa" con un VR di FL. Pertanto, l'operazione di esportazione prevede di convertire il valore dell'elemento di dati in un numero in virgola mobile (come mostrato nella tabella in Comportamento standard degli elementi di dati DICOM

Si verifica un conflitto di tipo perché tutti i tag con un VR di SL utilizzano il tipo di dati integer. Il tag viene quindi convertito in un tag privato e aggiunto alla colonna OtherElements.

Se per i dati di sequenza viene utilizzato un nome tag pubblico non di sequenza, si verifica una mancata corrispondenza del tipo. Di conseguenza, la sequenza viene trattata come se fosse un elemento di dati privati. Anziché utilizzare il nome del tag pubblico come nome della colonna nello schema BigQuery, viene utilizzato il numero esadecimale del nome del tag pubblico. Il numero esadecimale è di tipo stringa.

Esempi: esecuzione di query su elementi di dati pubblici e privati

Considera il seguente snippet di uno schema rappresentato come JSON. Lo schema è stato creato dopo l'esportazione dei dati DICOM in BigQuery.

[
  ...
  {
    "name": "SOPInstanceUID",
    "type": "STRING"
  },
  {
    "fields": [
      {
        "fields": [
          {
            "mode": "REQUIRED",
            "name": "Tag",
            "type": "STRING"
          },
          {
            "mode": "REPEATED",
            "name": "Data",
            "type": "STRING"
          }
        ],
        "mode": "REPEATED",
        "name": "OtherElements",
        "type": "RECORD"
      }
    ],
    "mode": "REPEATED",
    "name": "Tag_12345678",
    "type": "RECORD"
  }
  ...
]

L'esempio seguente mostra come eseguire una query sull'elemento di dati pubblici SOPInstanceUID. Per accedere al valore della colonna, esegui la seguente query:

#standardSQL
SELECT
  SOPInstanceUID
FROM
  `PROJECT_ID.DATASET_ID.TABLE_ID`

L'esecuzione della query restituisce un output simile al seguente:

[
  ...
  {
    "SOPInstanceUID": "0.0.000.000000.0.000.0000.0000000.0000.0000000000.000"
  },
  ...
]

Il seguente esempio mostra come eseguire query per dati privati non sequenziali. Esegui la seguente query sulla colonna OtherElements che si trova all'interno della colonna Tag_12345678. Tieni presente l'utilizzo dell'operatore UNNEST, che è obbligatorio perché stai eseguendo una query su un RECORD.

#standardSQL
SELECT
  Tag_12345678.OtherElements AS OtherElements
FROM
  `PROJECT_ID.DATASET_ID.TABLE_ID`,
  UNNEST(Tag_12345678) AS Tag_12345678

L'esecuzione della query restituisce un output simile al seguente, a seconda della quantità e del tipo di dati nella colonna Tag_12345678.OtherElements:

[
  {
    "OtherElements": [
      {
        "Tag": "Tag_12345678",
        "Data": [
          "DATA"
        ]
      }
    ]
  },
  {
    "OtherElements": [
      {
        "Tag": "Tag_12345678",
        "Data": [
          "DATA"
        ]
      }
    ]
  },
  {
    "OtherElements": [
      {
        "Tag": "Tag_12345678",
        "Data": [
          "DATA"
        ]
      }
    ]
  }
]

Schema JSON

Puoi esportare i metadati delle istanze DICOM in una tabella BigQuery con uno schema più semplice in cui i metadati completi delle istanze vengono archiviati come singola colonna JSON. Ciò può essere utile quando preferisci lavorare con la struttura JSON non elaborata dei metadati DICOM in BigQuery. È utile anche quando il numero di tag univoci in tutte le istanze DICOM supera il numero massimo di colonne consentite in una tabella BigQuery.

Per attivare lo schema JSON, imposta il campo schema_json in BigQueryDestination. Per maggiori dettagli sulla configurazione dello schema, consulta BigQueryDestination.

Quando lo schema JSON è abilitato, la tabella BigQuery avrà le seguenti colonne:

Nome campo Tipo Descrizione
StudyInstanceUID STRING Tag DICOM (0020,000D).
SeriesInstanceUID STRING Tag DICOM (0020,000E).
SOPInstanceUID STRING Tag DICOM (0008,0018).
SourceDicomStore STRING Il nome dell'archivio DICOM di origine. Questo campo viene incluso solo se l'opzione includeSourceStore è impostata su true nella configurazione di esportazione.
Type STRING Indica il tipo di operazione che ha attivato l'esportazione (ad es. CREATE, DELETE).
LastUpdated TIMESTAMP Timestamp dell'ultimo aggiornamento dell'istanza nell'archivio DICOM.
Metadata JSON Tutti i tag DICOM per l'istanza, archiviati in un unico oggetto JSON.
DroppedTags REPEATED STRING Elenco dei tag eliminati durante la conversione, in genere tag binari o molto grandi.
StorageClass STRING La classe di archiviazione dell'istanza (ad es. STANDARD, NEARLINE).
BlobStorageSize INTEGER Dimensioni dello spazio di archiviazione BLOB in byte.
StructuredStorageSize INTEGER Dimensioni dell'archiviazione strutturata in byte.

Esempio: esecuzione di query sulla colonna JSON dei metadati

Ecco un esempio di come eseguire una query su un tag DICOM specifico dalla colonna Metadata seguendo il supporto dei dati JSON di BigQuery. Questa query seleziona i tag PatientID e PatientAge:

#standardSQL
SELECT
  Metadata.PatientID AS patient_id,
  Metadata.PatientAge AS patient_age
FROM
  `PROJECT_ID.DATASET_ID.TABLE_ID`;

L'esecuzione della query restituisce un output simile al seguente:

/*-------------+---------------*
| patient_id   | patient_age   |
+--------------+---------------+
| "John-Doe"   | "042Y"        |
*--------------+---------------*/

Puoi adattare la query per estrarre altri tag DICOM dalla colonna JSON Metadata in base alle esigenze.

Passaggi successivi

Scopri di più sulle operazioni SQL standard di BigQuery e visualizza esempi.